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Preface 


When  I  first  began  work  on  logic  extraction  it  appeared  that  the  process  of  deriving  hierarchy 
from  a  “sea”  of  transistors  was  intuitive.  From  observing  engineers  working  on  layout  descriptions, 
it  appeared  that  the  human’s  ability  to  generate  simple  gate-level  schematics  from  a  transistor 
netlist  was  as  simple  as  a  bird  taking  to  flight.  However,  as  the  process  of  a  bird  flying  is  more 
complicated  than  a  matter  of  flapping  its  wings,  logic  extraction  is  more  complicated  than  a  matter 
of  just  matching  a  template  or  a  rule.  There  are  properties  of  the  bird  not  readily  apparent  to 
the  observer,  such  as  the  aerodynamics  of  the  wings  and  the  coordination  of  guidance  between  the 
tail  and  the  wings.  In  much  the  same  manner,  there  are  properties  of  logic  extraction  not  readily 
apparent  to  the  engineer,  such  as  connectivity,  internal  and  external,  of  an  extracted  component. 

Just  as  the  Wright  brothers  captured  the  essence  of  flight,  I  have  captured  the  essence  of 
logic  extraction.  For  the  past  several  years,  others  have  tried  to  perform  logic  extraction  and 
thought  that  they  had  achieved  it.  Now  that  logic  extraction  is  presented  in  a  formal  fashion  in 
this  dissertation,  I  hope  that  the  interested  individual  will  see  that  it  is  not  as  simple  as  it  appears. 
I  also  hope  that  using  logic  extraction  for  hardware-verification  will  become  more  popular  than 
simulation. 

I  wish  to  acknowledge  my  committee  for  the  time  they  invested  proof-reading  my  dissertation. 
My  committee  members.  Dr.  Frank  M.  Brown,  Dr.  Joanne  E.  DeGroat,  Dr.  Matthew  Kabrisky, 
Dr.  Mark  A.  Mehalic,  and  Dr.  Henry  Potoczny,  all  provided  helpful  comments  and  support  in  my 
research.  I  am  especially  grateful  to  Dr.  Frank  M.  Brown  for  keeping  all  the  details  in  the  right 
order  and  to  Dr.  Joanne  E.  DeGroat  for  keeping  the  macroview  of  the  research  in  perspective.  The 
talents  of  both  provided  the  appropriate  balance. 

I  also  wish  to  express  my  appreciation  to  the  Solid  State  Electronics  Directorate  of  Wright 
Laboratory.  Wright  Laboratory  provided  all  of  the  equipment  and  lab  space  for  my  work.  Working 
at  Wright  Laboratory  helped  provide  additional  insight  into  the  needs  of  the  Army  and  Air  Force, 


which  helped  guide  my  work.  I  am  indebted  to  Dr.  John  Hines  who  orchestrated  all  of  the  support 
and  Darrell  Barker  for  the  time  he  spent  ensuring  all  of  the  equipment  was  arriving  when  needed. 
I  also  want  to  mention  the  support  I  received  from  Luis  Concha  and  Captain  Karen  Serafino  who 
performed  related  work  to  my  research  as  well  as  Debora  McDivitt  and  Valerie  Holler  who  ensured 
I  arrived  at  various  TDY  locations  when  needed.  If  I  have  left  anyone  out,  I  apologize,  it  was  not 
intentional. 

The  dissertation  contains  nine  chapters  and  four  appendices.  Chapter  1  is  an  introduction  to 
the  dissertation.  Chapter  2  discusses  different  methods  used  in  comparing  behavioral  specifications, 
structural  specifications,  and  layout  specifications.  Chapter  3  contains  a  survey  of  past  attempts  at 
logic  extraction  and  a  description  of  the  structural  specification  and  layout  specification  used  in  the 
dissertation.  Chapter  4  demonstrates  the  consistency,  completeness,  and  termination  properties  of 
logic  extraction.  In  Chapter  5,  several  hardware  delay  models  used  to  demonstrate  the  feasibility 
of  pin-to-pin  critical  path  analysis  are  presented.  A  pin-to-pin  critical  path  analysis  procedure  with 
logic  extraction  is  discussed  in  Chapter  6.  Some  results  using  logic  extraction  are  presented  in 
Chapter  7.  Chapter  8  lists  some  limitations  that  impact  on  the  completeness  of  logic  extraction. 
Chapter  9  lists  conclusions  and  recommendations  for  future  work. 

Several  appendices  are  provided  with  the  dissertation.  They  serve  to  provide  some  background 
material  and  support  to  the  content  of  the  dissertation.  Appendix  A  contains  definitions  of  terms 
and  concepts  used  in  the  dissertation.  Appendix  B  contains  suggestions  for  improving  the  efficiency 
of  the  logic  extraction  process.  Appendix  C  is  a  demonstration  of  how  HOL  is  used  to  compare  a 
behavioral  specification  and  a  structural  specification.  Appendix  D  is  an  approach  to  translating 
VHDL  data-flow  models  to  VHDL  structural  models.  Finally,  Appendix  E  is  a  brief  discussion  of 
formal  methods. 
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Abstract 

A  Prolog-based  system  is  described  which  employs  logic-extraction  to  perform  hardware- 
verification.  The  extraction  rules  are  built  automatically  from  hierarchical  structural  VHDL  models, 
enabling  the  equivalence  of  a  structural  VHDL  description  and  a  layout  specification  to  be  verified. 
Pin-to-pin  critical-path  analysis  is  performed  within  the  logic-extraction  process;  many  noncritical 
paths  are  pruned  early,  making  pin-to-pin  critical  path  analysis  of  large  circuits  feasible.  It  is 
demonstrated  that  a  design  methodology  based  on  logic  extraction,  VHDL,  and  a  layout  tool  can 
provide  a  fabricated  functionally-correct  IC  design  without  circuit-level  or  switch-level  simulation. 
This  methodology  is  shown  to  be  practical  for  VLSI  designs  up  to  250,000  transistors  in  size.  The 
properties  of  correctness,  completeness,  and  guaranteed  termination  are  examined  for  the  extraction 


process. 


HARDWARE-VERIFICATION  THROUGH  LOGIC  EXTRACTION 


I.  Introduction 

The  Department  of  Defense  has  adopted  VHDL^  as  a  standard  means  of  documenting  digital 
designs.  A  structural  description  in  VHDL  is  an  orderly  top-down  hierarchical  decomposition 
of  a  circuit  into  sub-structures;  these  are  comprehensible,  at  every  level,  to  the  designer.  The 
ultimate  product  of  design,  however,  is  a  transistor-layout,  a  file  describing  large  numbers  (up  to 
hundreds  of  thousands)  of  interconnected  transistors.  This  file  is  used  to  manufacture  the  circuit  in 
silicon.  To  be  certain  that  the  design  complies  with  its  documentation,  the  designer  must  somehow 
convince  himself  that  the  layout — representing  a  seemingly-formless  mass  of  transistors  and  wires — 
is  a  realization  of  its  tidy  VHDL  description.  To  do  so  by  inspection  is  beyond  human  capability. 
Instead,  the  designer  today  must  revert,  in  software,  to  the  breadboard-testing  of  earlier  days:  he 
checks  his  design  by  conducting  an  input-output  experiment,  applying  a  sequence  of  inputs  to  a 
simulated  transistor-layout  and  comparing  the  resulting  outputs  with  those  that  would  be  produced 
by  the  VHDL  description. 

Though  greatly  assisted  by  VHDL,  stimulus-response  experiments  are  inherently  deficient 
as  a  way  to  ensure  the  compliance  of  a  design  with  its  documentation.  The  number  of  required 
test-inputs  increases  cistronomically  as  the  size  of  a  circuit  increases;  moreover,  memory-elements 
(present  in  most  circuits)  vastly  complicate  the  task  of  producing  and  interpreting  a  test-sequence. 
Designers  continue  testing-by-simulation  because  no  practical  alternative  has  been  available.  The 
work  presented  in  this  dissertation  provides  one  alternative. 

'  VHDL  is  an  acronym  for  VHSIC  Hardware  Descri,-)tion  Language  and  VHSIC  is  an  acronym  for  Very  High  Speed 
Integrated  Circuit.  VHSIC-class  integrated  circuits  include  designs  Itirger  than  100,000  transistors.  VHDL  is  IEEE 
Standard  1076-1987  (IEEE  87). 
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This  research  is  based  on  the  discovery  that  circuit-extraction,  a  well-known  technique,  may 
be  used  for  purposes  which  apparently  have  never  before  been  contemplated.  To  “extract”  a 
circuit  means  to  begin  with  a  low-level  description  of  its  structure  and  to  derive  a  higher-level 
description.  A  typical  extraction-system  might  accept  a  description  of  a  circuit  as  an  interconnection 
of  transistors  and  generate  a  description  of  the  same  circuit  as  an  interconnection  of  components 
such  cis  registers,  adders,  and  multiplexers. 

An  original  objective  was  to  develop  an  extraction-system  that  would  accept  a  transistor-level 
(or  gate-level)  description  of  a  circuit  and  would  generate  a  hierarchical  description  of  the  circuit 
in  VHDL.  Such  extraction  has  not,  to  our  knowledge,  been  possible  until  now,  and  would  be  of 
significant  value  to  the  digital-design  community.  It  has  turned  out  to  be  a  relatively  simple  by¬ 
product,  however,  of  the  system  that  has  emerged.  Called  GES  (Generalized  Extraction  System), 
the  system  performs  the  following  tasks; 

1.  Formal  Hardware- Verification.  GES  verifies  that  a  hardware  design  is  fully  compli¬ 
ant  with  its  hardware  documentation.  Supplied  with  a  structural  description  in  hierarchical 
VHDL,  GES  first  produces  a  custom  extractor  capable  of  extracting  only  the  specified  struc¬ 
ture.  GES  then  attempts  an  extraction.  If  the  attempt  succeeds,  the  design  is  verified  to 
be  100%  compliant  with  the  documentation.  If  the  attempt  fails,  then  the  design  may  de¬ 
viate  from  its  documentation  in  some  respect.  In  the  latter  case,  GES  provides  diagnostic 
information  which  enables  the  designer  quickly  to  determine  the  nature  and  location  of  the 
deviation. 

2.  Reverse-Engineering  of  Undocumented  Designs.  The  DOD  has  a  serious  problem  in 
replacing  parts  whose  functional  documentation  is  either  incomplete  or  non-existent.  Given  a 
low-level  description  (at  the  transistor  or  gate  level),  GES  will  produce  a  functional  description 
of  the  circuit.  GES  also  produces  timing  information  and  high-level  VHDL  documentation. 
The  “views”  of  the  circuit  that  are  produced  may  be  tailored  to  individual  requirements. 
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3.  Detection  and  Location  of  Errors  in  Design.  At  different  levels  in  the  process  of 
extraction,  design-rule  checks  are  performed  by  GES  to  identify  improperly  configured  com¬ 
ponents. 

4.  Assistance  in  Incremental  Documented  Design.  GES  enables  documentation  and 
layout  to  stay  in  step.  At  each  stage  of  design,  a  circuit  is  guaranteed  to  comply  with 
its  VHDL  description;  at  no  point  is  simulation  necessary.  The  direct  use  of  the  VHDL 
documentation  to  verify  a  layout  not  only  encourages  a  designer  to  keep  his  documentation 
current,  it  requires  him  to  do  so.  Documentation  is  typically  something  conjured  ex  post 
facio\  using  GES,  however,  the  documentation  becomes  an  essential  part  of  the  process  of 
design.  If  modifications  to  a  circuit-layout  are  required,  the  designer  using  GES  must  modify 
the  VHDL  documentation  first.  GES  thus  provides  a  useful  stimulus  to  keep  documentation 
current. 

5.  Critical-Path  Analysis.  GES  locates  pin-to-pin  critical  paths  in  a  layout.  The  requisite 
timing  calculations  are  based  on  distributed  resistance  and  capacitance  values  derived  from 
the  layout-description. 

The  process  of  formal  hardware- verification  presented  in  this  paper  combines  two  techniques. 
The  first  technique,  somewhat  similar  to  that  of  (Papas  88),  uses  a  rule-based  logical  extraction 
process  to  prove  100%  functional  compliance  between  a  structural  hardware  description  and  its 
associated  component  netlist.  For  true  verification  of  digital  hardware,  both  the  functional  and 
temporal  aspect  of  the  design  must  be  examined.  Thus,  a  second  technique,  involving  list  process¬ 
ing,  is  used  to  extract  pin-to-pin  critical  paths  from  the  structural  hardware  description  and  its 
associated  component  netlist.  The  critical  paths  of  the  hardware  model  and  the  component  netlist 
may  be  compared  to  ensure  that  the  timing  in  the  circuit  meets  the  restrictions  on  delays  specified 
in  the  digital  hardware  description. 
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Computer  Aided  Design  of  Hardware 


The  process  of  CAD  development  of  hardware  involves  several  steps  with  various  tools  to  aid  in 
the  design  process.  Figure  1  is  a  diagram  of  the  general  flow  of  the  design  process  as  it  has  existed, 
void  of  formal  hardware-verification.  This  process  begins  with  the  development  of  a  hardware 
behavioral  specification^.  Several  iterations  through  simulation  may  be  required  to  examine  the 
behavior  and  modify  the  behavioral  specification  until  it  matches  the  desired  performance.  Once 
a  behavioral  specification  has  been  established,  some  form  of  synthesis  is  employed  to  generate  a 
description  of  the  structural  specification.  Synthesis  in  this  context  is  performed  by  first  deriving  a 
netlist  from  the  behavioral  specification  then  optimizing  the  derived  netlist  into  its  implementation 
form.  The  synthesis  may  be  performed  manually  or  automatically.  The  structural  specification 
is  a  description  of  the  actual  hardware  component  to  be  realized.  At  this  point,  the  behavioral 
and  structural  specifications  are  simulated  to  generate  test  vectors  for  comparison.  Notice  that 
the  simulation  of  the  behavioral  specification  performed  at  this  point  is  in  addition  to  the  one 
performed  earlier  for  examining  the  behavioral  specification.  This  process  of  ensuring  conformance 
is  referred  to  as  validation. 

From  the  implementation  specification,  layout  of  the  integrated  circuit  is  performed,  again, 
through  synthesis.  As  before,  the  synthesis  may  be  either  manual  or  automatic.  From  the  gener¬ 
ated  layout-specification,  a  transistor  netlist  may  be  generated  for  use  in  a  switch-level  simulator 
(Terma  80).  The  results  produced  by  the  switch-level  simulator  are  then  compared  against  the 
results  of  the  structural-specification  simulation.  Once  the  layout-specification  is  shown  to  conform 
to  the  structural  specification,  it  is  transformed  into  a  format  that  may  be  sent  to  a  fabrication 
service  for  production  of  the  integrated  circuit^. 

Once  the  component  has  been  fabricated  it  must  be  tested  for  fabrication  flaws.  A  set  of 
test  vectors  is  run  on  the  integrated  circuit.  The  test  results  are  compared  against  the  results  of 

^See  Appendix  A  for  a  discussion  of  behavioral  and  structural  specifications. 

®For  the  purpose  of  this  presentation,  the  CALTECH  Intermediate  Format  (CIF)  was  chosen. 
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simulating  the  structural  specification.  Should  conformance  exist  between  the  integrated  circuit 
and  the  structural  specification,  the  integrated  circuit  is  assumed  to  be  correct. 

Figure  2  is  a  diagram  of  a  general  CAD  environment  that  includes  the  use  of  formal  hardware- 
verification.  With  the  use  of  formal  hardware-verification,  it  is  no  longer  necessary  to  simulate  the 
behavioral  specification  for  the  purpose  of  generating  test  vectors  for  the  structural  specification. 
The  simulation  of  the  structural  specification  is  necessary  only  for  comparison  against  the  final 
fabricated  component. 

Problem 

Using  simulation  to  validate  compliance  between  a  structural  specification  and  its  layout 
specification  is  no  longer  acceptable.  Designs  built  today  have  increased  in  complexity  well  beyond 
the  designs  built  through  breadboarding.  Though  simulation  was  sufficient  for  small  1,000-transistor 
designs,  designs  are  currently  being  constructed  on  the  scale  of  100,000  to  1,000,000  transistors.  To 
help  understand  the  complexity  of  the  problem,  consider  a  32-bit  adder. 

A  hardware  structure  typically  found  on  an  ASIC  today  is  a  32-bit  adder.  Such  an  adder  may 
be  implemented  in  a  number  of  different  ways  (Weste  85:310-331).  Regardless  of  the  implemen¬ 
tation,  for  input  there  are  32  bits  for  one  operand,  32  bits  for  a  second  operand,  and  a  carry  bit. 
The  total  number  of  input-bits  for  a  32-bit  adder  is  thus  65.  For  an  exhaustive  simulation^  at  least 
36,893,488,147,419,103,232  test  vectors  would  be  required.  If  we  assume  that  a  simulator  running 
today  could  handle  1,000  test  vectors  per  second,  the  system  would  complete  the  simulation  within 
1,169,884,834  years;  however,  simulation  to  this  extent  would  still  not  guarantee  equivalence  be¬ 
tween  the  structural  specification  and  the  layout  specification.  All  that  is  guaranteed  is  that  both 
the  structural  specification  and  the  layout  specification  are  equivalent  for  the  given  test-vector 
sequence.  Therefore,  performing  exhaustive  simulation  is  ineffective,  even  for  simple  designs. 

^The  next  chapter  provides  a  case  where  exhaustive  simulation  for  an  assumed  combinational  circuit  may  not  be 
sufficient,  requiring  even  more  test  vectors  than  shown  here. 
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Figure  2.  General  CAD  Development  Using  Formal  Hardware- Verification. 
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Solution 


One  way  to  overcome  the  deficiencies  of  simulation  is  through  logic  extraction.  Logic  extrac¬ 
tion  ensures  that  a  layout-specification  is  equivalent  to  a  structural  specification.  Further,  the  time 
that  it  takes  to  verify  the  equivalence  between  a  structural  specification  and  a  layout-specification 
of  designs  like  the  32-bit  adder  is  several  seconds  of  total  CPU  time.  As  a  result  of  the  research 
reported  here,  a  formal  basis  for  logic  extraction  is  presented,  logic  extraction  of  large  VHSIC-class 
chips  is  possible,  and  the  modest  CPU/memory  requirements  of  logic  extraction  make  verification 
of  1,000, 000-transistor  designs  a  reality.  Thus,  the  objective  of  this  research  is  to  establish  a  for¬ 
mal  definition  of  logic  extraction,  discuss  properties  of  logic  extraction  as  they  relate  to  formal 
hardware-verification,  and  demonstrate  that  logic  extraction  is  practical  for  VHSIC-class  designs. 

Overview 

GES  is  a  collection  of  programs  written  in  Prolog.  Prolog  is  used  as  the  vehicle  for  investigat¬ 
ing  and  implementing  logic  extraction,  since  logic  programming  is  directly  implemented.  A  logic 
program  is  a  collection  of  rules,  where  a  rule  has  the  form, 

A  ^ —  B\,. Bn 

and  n  >  0  (Sterl  86:8-15).  GES  consists  of  several  Prolog  programs  that  perform  the  following 
functions. 

1.  gts  -  the  logic  extraction  system 

2.  sim2pro  -  a  filter  for  translating  a  .sim  transistor  netlist  to  ges  format 

3.  vhdlSges  -  generates  ges  from  a  hierarchical  VHDL  structural  description 

4.  flatten  -  flattens  a  hierarchical  VHDL  structural  description  to  a  netlist  of  its  lowest-level 
components 
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5.  vhdl2ecpv  -  generates  ges  from  VHDL  for  extracting  critical  paths  in  a  netlist  generated  by 


flatten 

6.  vhdl2ecpl  -  generates  ges  from  VHDL  for  extracting  critical  paths  from  layout 

7.  ges2vhdl  -  generates  VHDL  structural  description  from  an  extracted  component  netlist 

8.  geng2v  -  generates  a  ges2vhdl  tool  from  a  collection  of  hierarchical  VHDL  structural  descrip¬ 
tions 


This  dissertation  will  focus  on  proving  several  properties  about  ges^.  These  properties  are  cor¬ 
rectness,  completeness,  and  termination.  By  demonstrating  correctness,  we  show  that  any  circuit 
successfully  extracted  by  ges  is  indeed  the  circuit  that  v/as  intended  to  be  built.  By  demonstrating 
completeness,  we  would  like  to  show  that  if  a  circuit  was  built  according  to  its  structural  specifica¬ 
tion,  ges  would  succeed  in  extracting  it;  however,  we  will  show  that  this  is  not  always  the  case  for 
logic  extraction.  We  will  also  show  that  logic  extraction,  through  ges,  is  guaranteed  to  terminate. 
Finally,  we  will  show  that  pin-to-pin  critical  path  analysis  is  possible  within  the  context  of  logic 
extraction. 


^GES  encompasses  all  of  the  Prolog  programs  enumerated  here.  ge$  is  the  Prolog  program  that  performs  the 
logic  extraction. 
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II.  Validation,  Synthesis,  and  Verification 


Several  approaches  to  ensuring  the  conformance  of  hardware  implementations  to  hardware 
specifications  are  reviewed  in  this  chapter.  These  approaches  are  generally  referred  to  as  validation, 
verification,  and  synthesis.  We  will  show  that  validation  is  inadequate  for  today’s  designs.  We  will 
also  show  that  the  assertion  of  “correct  by  construction”  made  by  designers  of  synthesis  tools  is  not 
true.  All  of  these  approaches  are  related  to  this  work  and  help  to  place  this  work  in  perspective. 
Before  examining  these  different  approaches,  the  generic  design  process  presented  in  Figure  1  and 
Figure  2  should  be  reviewed. 

Validation  Techniques 

Validation  is  concerned  with  demonstrating  the  functionality  of  a  given  circuit  for  a  selected 
set  of  input  stimuli  and  output  responses.  Stated  another  way,  validation  is  used  to  demonstrate, 
through  a  collection  of  results  or  test  vectors,  the  compliance  of  one  hardware  description  with 
another  hardware  description.  Simulation  is  also  used  as  a  name  for  the  process  of  validation. 
Exhaustive  simulation  is  not  feasible  for  any  but  the  simplest  of  digital  designs.  If  we  consider 
only  a  32-bit  register,  there  are  over  four  billion  possible  output  responses  for  any  one  given  input 
(Barro  84:438).  The  process  of  simulation  is  NP-complete  and  in  some  cases  may  not  be  exhaustive. 

Problems  with  design  validation  are  not  limited  to  its  intractability  alone.  Two  basic  types  of 
simulation,  event-driven  and  switch-level,  are  also  prone  to  complications  due  to  the  nature  of  the 
simulation  cycle.  Switch-level  simulators,  for  example,  are  generally  used  to  perform  simulation 
of  the  mask  layout  description  as  a  means  of  validation  (Terma  86).  This  type  of  simulation 
is  based  on  a  state  model.  As  such,  the  simulation  cycle  is  based  on  propagating  logic  values 
through  a  circuit  network  until  a  steady  state  is  reached.  For  combinational  logic  circuits,  this 
type  of  simulation  model  does  not  present  any  difficulty.  For  sequential  circuitry  and  systems 
with  oscillating  feedback  loops,  simulator  problems  are  generated  through  nonconverging  circuit 


10 


configurations.  Certain  other  sequential  circuits  can  also  introduce  race  conditions  that  cannot 
be  handled.  Circuits  that  have  oscillators  as  part  of  their  normal  makeup  never  converge  to  a 
steady  state  value  once  they  are  set  to  oscillate.  Since  the  circuit  never  converges  to  a  steady  state, 
simulation  using  switch-level  simulators  is  not  practical. 

Using  switch-level  simulators  to  identify  errors  in  a  circuit  may  also  prove  difficult.  Consider 
the  circuits  shown  in  Figure  3(Bryan  87).  Should  the  sequence  of  test  vectors  for  (A,B)  be  chosen 
as  ((0,0),  (0,1),  (1,1),  (1,0)),  the  result  for  (A,B,Out)  would  yield  the  sequence  ((0,0,1),  (0,1,0), 
(1,1,0),  (1,0,0)).  The  same  sequence  would  be  seen  for  both  the  correct  NOR-gate  implementation 
and  the  flawed  NOR-gate  implementation.  The  capacitive  storage  on  the  flawed  NOR-gate  circuit 
allows  for  a  logical  0  on  Out  when  (A,B)  is  set  to  (1,0).  However,  had  the  sequence  for  (A,B)  been 
chosen  as  ((0,0),  (1,0),  (1,1),  (0,1))  the  flaw  would  have  been  detected  for  (A,B,Out)  as  (1,0,1). 
This  example  demonstrates  that  flaws  in  a  combinational  circuit  may  not  be  found  even  when  an 
“exhaustive”  sequence  is  used  to  simulate  the  circuit’s  behavior. 


Figure  3.  Circuit  Diagrams  for  a  NOR-Gate  and  Flawed  NOR-Gate. 

Fivent-driven  simulators  are  based  on  propagating  signals  using  time- value  pairs  (IEEE  87). 
This  type  of  simulation  allows  for  delay  to  be  considered.  Sequential  circuits  that  oscillate,  then,  do 


11 


not  cause  undeterminable  results.  This  type  of  simulation  usually  is  performed  on  digital  circuits 
at  the  gate  level. 

Synthesis 

The  purpose  of  this  section  is  to  discuss  problems  of  using  automatic  synthesis  alone  in  the 
hardware  design  process.  Ideally,  synthesis  translates  a  register-transfer  level  (RTL)  description 
(structural  specification)  directly  to  a  layout-specification.  However,  practical  synthesis  is  a  two- 
step  process  involving  translation  from  a  RTL  description  to  a  component  netlist  followed  by  an 
optimization  step.  The  translation  portion  of  synthesis  maps  a  RTL  description  of  a  design  in  a 
hardware  description  language^  to  a  gate-level  netlist  (deGeu  89:27).  Afterwards,  optimization  of 
the  gate-level  netlist  is  performed.  The  optimization  step  may  be  based  on  an  optimization  process 
using  the  Quine-McCluskey  (McClu  56)  method  or  usi  a  rule-based  substitution  process. 

The  first  problem  with  synthesis  concerns  the  completeness  of  the  required  design  specifi¬ 
cation.  The  behavior  of  the  design  must  bt  described  completely  in  order  for  synthesis  tools  to 
generate  a  hardware  description.  If  we  assume  a  specification  that  describes  the  output  condition 
when  A=B=1  to  be  1  and  the  output  condition  for  A=B=0  to  be  0  without  further  information, 
synthesis  cannot  be  performed.  We  may  assume  don’t  care  conditions  for  the  other  two  situations; 
however,  this  condition  must  be  explicitly  stated.  The  designer  may  be  required  to  fully  describe 
a  given  design  even  when  doing  so  may  be  highly  inconvenient. 

Synthesis  is  a  highly  complex  process.  To  further  complicate  the  problem,  VHDL  is  composed 
of  many  procedural  and  declarative  language  constructs.  The  complexity  of  synthesis  ai  d  the  many 
features  of  VHDL  can  contribute  to  generating  inadvertant  errors  during  the  mapping  to  a  gate- 
level  netlist,  optimization,  or  the  mapping  to  a  layout  specification  (Devad  88:182).  Tl.erefore, 
synthesis  needs  to  be  checked  by  a  verification  system  to  ensure  conformance. 

'VHDL  is  the  standard  hardware  description  language  used  for  a  RTL  description. 
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Another  problem  with  synthesis  is  the  limited  set  of  design  solutions  that  are  provided.  Gen¬ 
erally,  a  fixed  generation-pattern  from  a  RTL  representation  in  VHDL  to  a  gate-level  netlist  exists 
for  a  given  language  construction.  For  example,  a  case  statement  in  VHDL  may  be  mapped  di¬ 
rectly  to  a  series  of  multiplexers  m  hardware.  Some  synthesis  tools  provide  the  means  to  make  space 
versus  area  tradeoffs  during  optimization  (deGeu  89:29).  However,  these  solutions  are  equivalent 
solutions.  Other  solutions  may  exist  that  meet  the  criteria  of  the  behavioral  specification,  but  are 
not  equivalent.  For  the  purpose  of  illustration,  assume  that  a  designer  wishes  to  incorporate  a  full 
adder  into  a  design.  Assume  also  that  previously  fabricated  components  exist,  but  with  two  full 
adders  on  a  chip.  The  chip  with  two  full  adders  would  suffice  for  the  needs  of  the  designer;  how¬ 
ever,  the  synthesis  system  would  tell  the  designer  to  design  a  new  component  comprising  one  full 
adder.  This  problem  limits  the  designer  to  a  confined  solution  space  when  investigating  alternative 
solutions  might  yield  better  designs. 

The  level  where  synthesis  is  performed  is  important.  When  an  expert  manually  synthesizes 
a  structural  specification  from  a  behavioral  specification,  some  mental  rechecking  of  the  behavioral 
specification  is  performed.  Flaws  or  poor  assumptions  made  in  the  behavioral  specification  are 
sometimes  found  while  the  expert  is  exploring  the  solution  space  of  the  structural  specification. 
Synthesis,  however,  doesn’t  provide  this  opportunity  to  reflect  on  the  original  behavioral  specifica¬ 
tion.  Thus,  the  flaws  and  poor  assumptions  in  the  behavioral  specification  are  incorporated  into 
the  final  product. 

Synthesis  systems  are  generally  based  upon  Boolean  manipulation  techniques.  If  the  design 
specification  is  not  based  on  {0,1}  then  the  Boolean  manipulation  techniques  used  in  the  synthesis 
approach  will  not  yield  an  implementation  description  that  may  be  compared  to  the  behavioral 
specification.  Assume  that  the  behavioral  specification  for  a  given  design  is 

out  =  {xyV  xzW  x/ z).  (1) 
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A  synthesis  system  would  perform  optimization  on  Eq  1  yielding  the  following  transformation. 


{xyV  xzV  x/z)  {xyW  y'z)  (2) 

Through  synthesis,  the  expression  on  the  left  of  Eq  2  may  be  seen  to  be  equivalent  to  the  expression 
on  the  right.  The  unannounced  assumption  made  by  the  synthesis  system  in  this  case  is  that  the 
above  expression  is  true  for  a  Boolean  algebra.  However,  should  we  choose  the  case  where  the  set  of 
possible  values  used  is  {0,X,1}^  great  difficulty  arises  in  generating  comparable  simulation  results 
before  and  after  synthesis. 

Shown  in  Figure  4  is  an  uncomplemented  distributive  lattice®  ^  and  a  collection  of  operator 
tables  defined  for  {0,X,1}.  The  uncomplemented  distributive  lattice  and  the  collection  of  operator 
tables  are  not  the  same  and  differ  through  the  interpretation  of  complement.  For  a  true  complement 
to  exist,  the  following  system  of  equations  must  be  satisfied  (Rudea  74:3-4)  (Donne  68:101). 

uAu'  =  0 

u  V «'  =  1 

A  true  complement  does  not  exist  for  the  operator  tables  since  the  system  of  equations  cannot 
be  satisfied  for  u  —  X .  Attempting  to  force  a  complement  operation  for  {0,X,1}  only  succeeds  in 
generating  problems  in  simulation.  An  example  can  be  constructed  to  illustrate  this  problem. 

For  the  previous  transformation,  Eq  1,  assume  x  =  z  =  I  and  y  =  X.  The  result  for  both 
equations  of  the  transformation  would  then  be  the  following. 


{xy  V  xzV  i/z) 


(3) 


^This  set  is  from  the  current  EIA  modeling  standards  for  VHDL  (EIA  89).  Such  a  set  of  values  is  used  to  perform 
hazard  analysis  in  CMOS  circuits 

®A  value  system  described  in  this  manner  is  not  unusual  and  was  first  proposed  by  Lukasiewicz  in  1920 
(Resch  69:22). 

^A  discussion  on  lattices  may  be  found  in  (Donne  68).  In  particular  ,  a  Boolean  algebra  is  a  complemented 
distributive  lattice  (Donne  68;.55-59, 224-249).  The  relation  between  a  Boolean  algebra  and  the  postulates  that 
define  a  complemented  distributive  lattice  are  stated  explicitly  in  (Rudea  74:4). 
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Figure  4.  Lattice  and  Operator  Tables  for  {0,X,1}. 

(xyVj/z)  =  X  (4) 

Fqs  3  and  4  have  different  results  leading  the  user  to  believe  that  the  synthesis  tool  has  failed. 
However,  the  result  of  synthesis  using  consensus  to  absorb  the  xz  term  is  valid  for  a  Boolean  Algebra. 
This  illustration  demonstrates  the  problem  of  comparing  results  through  simulating  a  synthesized 
structural  specification  from  a  behavioral  specification  when  a  many-valued  logic  system  is  used. 

Simulation  using  a  many-valued  logic  system  is  not  the  only  problem  encountered  when 
synthesis  is  used  in  Eq  2.  The  designer  may  desire  to  have  the  xz  term  included.  Without  the  xz 
term,  a  spike  might  be  induced  into  a  circuit  when  transitioning  from  the  xy  term  to  the  y'z  term. 
Using  synthesis  in  some  situations  may  produce  large  combinational  logic  circuits  with  dangerous 
transient  responses  to  certain  input  stimuli. 

Although  there  are  problems  with  synthesis,  its  use  is  beneficial  in  some  cases.  In  situations 
where  certain  designs  described  by  a  hardware  description  language  are  easily  synthesized,  synthesis 
can  provide  better  hardware  solutions  than  can  humans.  When  working  with  large  circuit  designs, 
humans  can  lose  attention  while  optimizing  a  circuit.  Synthesis  tools,  however,  work  as  vigorously 
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to  optimize  the  last  portion  of  a  circuit  as  they  do  the  first  part.  Most  synthesis  tools  also  perform 
some  self-verification  of  the  hardware  they  have  generated,  to  help  reduce  the  possibility  of  intro¬ 
ducing  errors.  Synthesis  requires  reasonable  human  guidance  and  a  verification  system  for  proper 
operation. 

Verification  Methods 

As  opposed  to  validation,  verification  is  the  process  of  proving  compliance  between  one  hard¬ 
ware  specification  and  another  hardware  specification.  Verification  methods  are  beised  on  a  sound 
mathematical  foundation.  Methods  for  formal  hardware-verification  range  from  automatic 
(Boyer  79)  to  manual  (Gordo  89).  The  Boyer-Moore  method  performs  most  of  its  theorem  proving 
through  induction,  whereas  HOL  is  open  to  theorem  proving  through  many  techniques.  One  of  the 
more  common  techniques  of  theorem  proving  in  HOL  is  through  rewriting  of  goals  and  dividing 
goals  into  a  conjunction  of  subgoals. 

The  capacity  to  perform  formal  hardware-verification  is  based  upon  the  ability  to  express 
hardware  descriptions  in  a  theorem  form.  Some  formal  hardware-verification  systems  require  that 
a  description  of  the  hardware  be  in  a  specification  language.  The  specification  language  may  either 
be  the  language  of  the  proof  system  or  some  hardware  description  language  that  can  be  translated 
into  the  language  of  the  proof  system. 

The  relationships  among  the  behavioral  specification,  structural  specification,  and  layout 
specification,  are  usually  characterized  as  follows: 

Structural  Specification  ^  Behavioral  Specification  (5) 

Structural  Specification  O  Layout  Specification  (6) 
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Relation  6  is  necessary  to  ensure  that  the  actual  hardware  and  documentation  match  explicitly. 
Contrary  to  intuition®,  Relation  5  expresses  the  logical  requirement  that  the  structural  specification 
is  within  the  domain  described  by  the  behavioral  specification. 

The  implicative  relation  between  a  behavioral  specification  and  a  structural  specification  can 
be  shown  through  several  examples.  For  the  first  example,  assume  the  domain  of  discourse  to  be  the 
set  of  integers.  Considering  a  behavioral  specification,  =  25,  and  two  structural  specifications, 
X  =  5  and  x  =  —5,  we  have 


(x  =  5)  =>  (x^  =  25) 

(x  =  —5)  ^  (x^  =  25). 

The  equation  (structural  specification)  x  =  5  is  a  solution  (implementation)  of  the  equation  (be¬ 
havioral  specification)  x^  =  25.  In  Appendix  C  is  a  digital-hardware  example  of  the  implicative 
relation  between  several  structural  specifications  and  a  behavioral  specification. 

Further  information  regarding  formal  hardware-verification  techniques  may  be  found  in  sev¬ 
eral  sources.  An  extensive  survey  of  formal  hardware-verification  is  in  (Camur  88).  Some  of 
the  most  commonly  referenced  methods  include  Higher-Order  Logic  (Gordo  89),  Boyer-Moore 
(Boyer  79),  and  TEMPURA  (Moszk  86).  A  discussion  on  temporal  logic  approaches  is  presented  in 
(Galto  87).  A  tutorial  for  HOL  has  recently  been  published  (Gordo  89).  Furthermore,  a  theoretical 
discussion  of  HOL  may  be  found  in  (Gordo  88).  A  demonstration  of  how  HOL  is  used  in  formal 
hardware-verification  may  be  found  in  Appendix  C. 

®Tho8e  initially  exposed  to  simulation  as  a  form  of  design  validation  tend  to  see  this  relation  as 
Behavioral  Specification  ^  Structural  Specification.  This  bias  is  brought  about  by  the  thought  that  whatever 
stimulus-response  patterns  result  from  the  behavioral  specification  must  also  result  from  the  structural  specification. 
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Summary 


The  process  of  simulation  is  neither  correct  nor  complete.  A  circuit  may  not  match  a  design, 
but  simulation  may  lead  the  designer  to  believe  the  design  is  constructed  in  compliance  with 
its  structural  specification.  Additionally,  a  circuit  may  comply  with  its  structural  specification, 
but  problems  with  the  simulator  paradigm  may  prevent  demonstration  of  proper  performance. 
Despite  these  shortfalls,  simulation  is  still  necessary  for  generating  test  vectors  for  testing  fabricated 
components. 

Synthesis  is  not  always  sufficient  for  guaranteeing  correct  designs  and  may  produce  unexpected 
results.  Thus,  synthesis  requires  the  use  of  formal  hardware-verification  to  ensure  the  results  of 
synthesis  are  correct.  In  contrast  to  design  validation,  formal  hardware-verification  can  verify  a 
design  for  all  possible  inputs  and  outputs  in  a  tractable  manner  (Barro  84:438). 

We  have  shown  that  a  structural  specification  is  a  solution  to  a  behavioral  specification,  but 
not  necessarily  a  unique  one.  Since  a  structural  specification  is  a  reflection  of  the  actual  hardware, 
it  must  match  the  layout  specification  explicitly.  Formal  hardware-verification  methods  should  be 
used  to  show  that  the  layout  specification  is  equivalent  to  the  structural  specification.  As  a  formal 
method,  logic  extraction  shows  equivalence  between  the  layout  specification  and  the  structural 
specification. 
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III.  Logic  Extraction,  VHDL,  and  Transistor  Netlists 


A  Survey  of  Logic  Extraction 

Logic  extraction  has  been  attempted  by  several  researchers  prior  to  this  research.  Previously, 
logic  extraction  was  viewed  as  simply  a  matter  of  matching  a  few  subcomponents  to  a  template 
and  replacing  them  with  a  single  component;  however,  problems  were  encountered  with  component 
connectivity  when  using  this  simple  approach.  Additionally,  the  size  of  the  circuit  that  could  be 
extracted  was  less  than  10,000  transistors  in  size. 

An  informal  description  of  logic  extraction  through  GES  is  first  presented.  Afterwards,  de¬ 
scriptions  of  previous  approaches  are  provided.  As  each  approach  is  discussed,  the  inherent  problems 
with  each  approach  are  identified. 

Logic  Extraction  through  GES  Three  functions  are  performed  in  the  extraction  process 
shown  in  Figure  5.  These  three  functions  are  identifying  the  subcomponents  that  form  the  com¬ 
ponent,  checking  that  internal  nodes  do  not  have  external  connections,  and  checking  for  internal- 
external  connection  inconsistencies.  By  extraction,  the  appropriate  components  and  interconnec¬ 
tions  are  identified.  When  the  components  are  identified,  additional  checks  are  necessary  to  ensure 
that  different  variable  labels  contain  different  values*.  Checking  that  the  internal  connections  of  a 
component  do  not  connect  with  another  component  external  to  the  component  being  extracted  is 
important.  From  Figure  5,  the  node  named  INTERN  “disappears”  from  the  overall  circuit  once 
the  D-latch  is  extracted.  If  the  node  named  INTERN  is  connected  to  some  other  component 
external  to  the  D-latch,  connectivity  information  is  lost. 

Prolog  vs.  Forward- Chaining  Expert  Systems  Rule-based  methods  implemented  in 
forward-chaining  systems  like  OP.S5  (Spick  85),  OPS83,  or  CLIPS  (Yaros  89)  suffer  from  two  prob¬ 
lems.  The  first  problem  is  inherent  to  the  extraction  process.  The  second  problem  is  inherent  to 

'Within  Prolog,  different  variable  labels  are  allowed  to  contain  the  same  value.  However,  when  using  different 
variable  labels  for  hardware  design,  different  electrical  connecticwis  are  implied. 
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Figure  5.  Logic  Extraction. 

forward-chaining  systems.  The  types  of  forward-chaining  systems  that  fall  within  the  realm  of  this 
discussion  are  shown  in  the  pictorial  representation  of  Figure  6.  The  forward-chaining  system  is 
divided  into  parts.  The  first  part  consists  of  the  rules.  Each  rule  has  a  left-hand  side,  LHS,  and  a 
right-hand  side,  RHS.  The  LHS  is  a  set  of  conditions  that  must  be  met  in  order  to  carry  out  the 
actions  in  the  RHS.  The  working  memory  contains  the  facts  and  context  of  the  forward-chaining 
system.  The  context  is  a  stack  of  all  partially  matched  and  fully  matched  rules.  An  iterative  process 
of  matching,  conflict  resolution,  and  acting  is  carried  out  until  there  are  no  more  fully  matched  rules 
to  act  on.  The  conflict  resolution  portion  of  the  iterative  process  determines  which  fully-matched 
rule  to  act  on. 

Figure  7  is  an  example  of  what  appears  to  be  a  lAID  gate;  however,  an  internal  connection, 
Int,  to  another  component,  COMP,  suggests  otherwise.  Before  extracting  a  component,  its  in¬ 
ternal  connections  must  be  checked  to  ensure  they  are  not  connected  to  the  external  connections 
of  the  component  being  extracted  (“local”  connectivity)  and  to  ensure  they  are  not  connected  to 
another  component  (“global"  connectivity).  Once  the  component  is  recognized  and  extracted,  the 
internal  node  disappears,  thus  connectivity  information  is  lost.  Local  connectivity  is  eeisy  to  check 
within  an  extraction  rule,  since  all  of  the  connection  information  is  available.  Global  connectivity 
is  more  difficult  to  check.  It  is  not  readily  apparent  how  rules  in  forward-chaining  systems  may 
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if  conditions  then  perform  actions 

LHS  — >  RHS 

Process 

1.  Match 

2.  Conflict  Resolution  OR  halt 

3.  Act 

4.  Go  to  step  1 


Rules 


Working  Memory 


Figure  6.  Forward-Chaining  System. 

be  constructed  to  solve  the  internal-global  connectivity  problem.  Such  rules  for  internal-global 
connectivity  checks  are  not  addressed  in  (Spick  85)  (Yaros  89). 


Figure  7.  Possible  NAND  Gate. 


Secondly,  forward-chaining  systems  are  best-suited  for  heuristic  solutions  to  problems  of  an 
intractable  or  diffuse  nature.  The  “working  memory”  of  an  expert  system  is  one  element  where 
impact  on  performance  is  observed.  Working  memory  contains  both  the  facts  (in  this  case,  a 
transistor  netlist)  and  the  context  of  the  system  (a  stack  of  fully  matched  and  partially  matched 
rules).  A  large  number  of  additions  or  deletions  of  facts  can  result  in  costly  memory  management 
overhead.  Stored  within  the  context  of  working  memory  is  a  list  of  matched  and  partially  matched 
rules  Having  several  rules  governing  component  configurations  from  transistors  among  a  fact-base 
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of  several  thousand  transistors  can  result  in  the  context  area  of  working  memory  exceeding  the 
capacity  of  the  system.  A  CLIPS  implementation  of  logic  extraction  (Yaros  89)  developed  along 
the  lines  of  an  OPS5  implementation  of  logic  extraction  (Spick  85)  demonstrated  that  a  system  of 
several  matching-rules  (gate-types)  and  2,000  transistor-facts  exceeded  100  MegaBytes  of  available 
memory  during  execution. 

Aside  from  the  large  memory  problems,  it  turns  out  that  conflict  resolution  is  of  little  im¬ 
portance.  The  component  netlist  may  be  extracted  simply  by  applying  the  rules  sequentially.  The 
overhead  involved  in  resolving  conflicts  between  rules  ready  to  fire  is  an  unnecessary  expense.  Fur¬ 
ther,  the  inability  to  directly  control  the  rule-firing  order  makes  the  logic  extraction  process  difficult 
to  fine-tune  for  efficiency  in  an  expert  system  environment. 

Prolog  vs.  Oth  I-  Languages  Prolog  was  chosen  as  the  implementation  language  over 
procedural  languages  and  Lisp  for  several  reasons.  The  logic  extraction  process  involves  searching 
and  pattern  matching.  Prolog  is  naturally  suited  to  searching  and  pattern  matching.  Expressing 
the  logic  extraction  process  in  Prolog  allowed  for  rapid-prototyping  of  ideas.  Seventy  lines  of  Prolog 
code,  easily  developed,  implemented  a  portion  of  the  extraction  process  being  performed  by  a  C- 
code  implementation  of  over  5,000  lines  (Linde  88).  Further,  reliable  Prolog  implementations  exist 
today  (Quint  88).  Finally,  there  is  an  accepted  standard  for  Prolog  (Clock  87b). 

Summary  Work  with  logic  extraction  has  been  reported  in  (Spick  85)  (Boehn  88).  Other 
work  that  performs  comparisons  of  transistor  networks  to  their  original  structural  descriptions 
(either  an  HDL  or  schematic)  do  so  by  graph-based  methods  (Ebeli  83)  (Takas  88),  rule-based 
methods  (Takas  88)  (Papas  88),  or  other  methods  (Boehn  88)  (Takas  88)  (Spick  83).  Though  one 
method  does  extr.act  some  timing  information  at  the  gate  level  (Boehn  88),  none  performs  any 
type  of  critical  path  analysis  in  conjunction  with  the  extraction  process.  A  report  on  critical  path 
analysis  within  the  extraction  process  is  in  (Dukes  91a). 
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The  Representation  of  Hardware  Structure  Through  VHDL 


VHDL  Syntax  This  section  details  the  VHDL  language  constructs  accepted  by  vhdl2ges. 
Several  examples  of  acceptable  structural  VHDL  models  are  provided.  The  VHDL  language  con¬ 
structs  are  taken  from  the  Syntax  Summary  of  (Dukes  91b:5).  At  a  minimum,  the  VHDL  descrip¬ 
tion  must  contain  the  following. 

entity  identifier  is 
/ormaLport.clause 
end  enh<y_simple_name  ; 

architecture  identifier  of  en/i<y_name  is 
component  identifier 
/ocaLport.clause 
end  component; 
begin 

instanhationjabel  ; 

componcn<_name  port.mapjispect  ; 
end  arcAi<ec<«rie^imple_name  ; 


Below  is  an  example  of  a  VHDL  description  conforming  to  the  above  description. 


entity  comp  is 

port  (A  ;  in  bit); 
end  comp; 

airchitecture  structure  of  comp  is 
component  sub.comp 
port  (A  :  in  bit); 
end  component; 
begin 

sub.compOO  :  sub.comp  port  map  (A); 
end  structure; 


Additional  VHDL  language  constructs  supported  are  shown  below, 
signal  identifierJist  :  subtypeJndication; 
alias  identifier  :  subtypeJndication  is  name; 


All  other  VHDL  language  constructs  are  ignored. 
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Properties  of  Structural  VHDL  There  are  several  properties  and  relations  expressed  by 
a  structural  VHDL  description.  Those  properties  and  relations  concern  the  component-to-entity 
relation,  properties  of  signal  names,  and  properties  of  aliases.  Further,  there  are  the  restrictions 
that  at  least  one  signal  must  be  in  the  port  and  there  must  be  at  least  one  instantiated  component 
in  the  architecture  body. 

The  relation  between  the  entity  and  its  respective  components  is  aone-to-many  relation.  This 
relation  is  shown  in  Figure  8.  Importantly,  this  relation  is  bidirectional  in  that  an  entity  may  be 
decomposed  into  a  collection  of  components  or  a  collection  of  components  may  make  up  an  entity. 
In  the  case  of  logic  extraction,  the  emphcisis  is  on  finding  a  collection  of  components  that  make  up 
an  entity. 


Figure  8.  Relation  Between  an  Entity  and  Components. 

The  port  of  an  entity  lists  the  signals  through  which  the  entity  communicates  to  exterior 
components.  The  port  forms  a  boundary,  isolating  the  interior  components.  The  signals  declared 
in  the  declarative  area  of  the  architecture  imply  “wires”  through  which  the  components  of  the 
interior  of  the  entity  communicate.  Some  important  distinctions  between  signals  of  the  port  and 
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signals  of  the  architecture’s  declarative  area  arise.  For  clarity  of  the  discussion,  we  will  use  signalse 
to  denote  signals  of  the  port  and  signalsa  to  denote  signals  of  the  architecture  declarative  area. 

For  the  signals  of  signalsa  and  signalsg,  we  will  informally  describe  a  logical  prop¬ 
erty  called  not.connccted{signalSa,signalse).  We  may  also  refer  to  the  logical  property 
not.connected{signalsa,  signalse)  as  not_connected/2^.  The  properties  of  not_connected/2 
are  as  follows. 

1.  None  of  the  signals  of  signalsa  may  be  a  member  of  signals^. 

2.  Every  signal  of  signalsa  is  unique. 

The  two  properties  of  not_connccted/2  reflect  the  semantics  of  VHDL,  The  first  property  of 
not_connected/2  enforces  the  requirement  in  VHDL  that  a  signal  may  only  be  declared  in  the  port 
of  the  entity  or  in  the  architectural  declarative  part.  The  second  property  of  not_connected/2 
represents  that  fact  that  each  signal  declared  in  the  architectural  declarative  part  represents  a 
unique  wire.  However,  the  signals  of  the  port  map  may  be  interconnected  when  the  component  is 
instantiated  at  a  higher  level  in  a  VHDL  structural  specification. 

As  for  the  visibility  of  the  signals  of  signalsa,  ^  property  f  ind.anomaly{component ,  signalsa ) 
will  be  defined.  The  property,  find.anomaly{component,  signals  a),  explicitly  represents  the  fact 
that  none  of  the  signals  of  signalsa  may  be  connected  to  components  outside  the  entity  under 
consideration.  In  essence,  find,anomaly{component,signalsa)  expresses  the  confinement  of  the 
scope  of  the  signals  of  signalsa  to  the  interior  of  the  architecture  of  the  entity  under  consideration. 
Implicitly,  the  signals  of  signalse  may  be  seen  on  the  outside  and  inside  of  the  entity. 

Aliases  in  VHDL  provide  a  basis  for  renaming  signals  of  signalsa-  Any  time  an  alias  is 
encountered,  it  is  replaced  with  the  appropriate  signal  of  signalsa  or  signalsg. 

^  A  Prolog  program  is  identified  by  its  functor  and  arity  as  /unctor/arily.  The  functor  is  the  name  of  the  Prolog 
program  and  the  arity  is  the  number  of  parameters  passed  to  the  Prolog  program. 
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Transistor  Netlist  Representation 


GES  does  not  extract  components  directly  from  a  layout  specification.  GES  performs  logic 
extraction  on  a  transistor  netlist  derived  from  a  layout  specification.  The  transistor  netlist  may 
be  generated  from  a  layout  specification  from  one  of  several  CAD  tools  that  already  exist  for 
this  purpose.  Ihis  section  describes  the  input  format  for  a  transistor  netlist.  Also  presented  is  a 
mapping  from  a  transistor-netlist  format  produced  by  a  CAD  tool  to  the  transistor-netlist  format 
used  for  logic  extraction. 

Generating  Transistor  Netlists  from  Magic  One  form  for  a  transistor  netlist  is  that 
described  in  (Terma  86).  This  form  was  chosen  since  it  was  derived  from  the  mctsk  layout  form  of 
magic  used  in  (Calif  86).  One  process  of  generating  the  transistor  netlist  begins  in  magic  by  using 
the  :cif  command.  The  :cif  command  in  magic  produces  a  mask  layout  file  in  CIF^.  Afterwards, 
mextra  reads  in  the  CIF  file  and  produces  a  transistor  netlist  file.  The  record  format  for  a  transistor 
is 


type  gate  source  drain  length  vidth  xpos  ypos 

where  type  is  one  of  e,  p,  or  n  for  enhancement  mode  transistor,  p-type  transistor,  or  n-type 
transistor,  respectively.  The  second  through  fourth  fields,  gate,  source,  and  drain,  describe  three 
of  the  four  terminals  of  the  MOS  transistor  used.  The  bulk  (or  substrate)  is  assumed  to  be  biased 
correctly  and  is  not  included.  The  fifth  and  sixth  fields,  length  and  width,  describe  the  channel 
length  and  channel  width  of  the  MOS  transistor.  The  seventh  and  eighth  fields,  xpos  and  ypos, 
are  the  location  coo-dinates  of  the  transistor. 

An  alternate  route  for  extracting  a  transistor  netlist  from  a  magic  layout  also  exists.  The 
:extract  command  in  magic  creates  a  hierarchical  form  of  the  layout,  in  .ext  format,  currently 

^CALTECH  Intermediate  Format  (CIF)  is  one  layout  format  used.  Another  common  layout  format  is  CDS  II. 
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residing  in  magic.  A  series  of  extraction  files  is  created  that  reflects  the  cell  hierarchy  used  in  magic. 
A  tool  called  extSsim  is  then  used  to  generate  the  transistor  netlist  form. 

Converting  Transistor  Netlists  to  Prolog  Clause  Form  If  the  mexira  tool  is  used  on 
a  GIF  file,  the  transistor  netlist  will  be  created  with  the  n-type  and  p-type  transistors  described 
as  e  and  p  for  their  types,  respectively.  If  the  ext2sim  tool  is  used,  the  transistor  netlist  will  be 
created  with  n-type  and  p-type  transistors  described  as  n  and  p  for  their  types,  respectively.  Thus, 
a  transistor  generated  from  mexira  as 

e  a_XirQR_c#17  1520  GKD  300  1200  706200  -20560 

would  appear  in  Prolog  clause  form  as 

n{nAJi NORjCll,  nl520,  ngnd,  30u,  1200, 706200,  -20550). 

A  transistor  generated  from  exi2sim  eis 

p  20/4_l/A_in_naiid  Vdd  20/4_l/probe  300  1200  12172  101 
would  appear  in  Prolog  clause  form  as 

p{n2M.\AJN.NAND,  nvdd,  n204.  PROBE,  300, 1200, 12172, 101). 

The  general  transistor  netlist  format  in  Prolog  is  shown  below. 

type p{gate p ,  source p,  drainp,  xpos,  ypos). 

The  following  mappings  are  used: 


type  t—  typep 
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p 

P 

n 

H- ► 

n 

e 

n 

gate 

H- ► 

gatep 

node 

nNODE 

Vdd 

nvdd 

GND 

ngnd 

Gnd 

*— ► 

ngnd 

source 

1— 

source  p 

node 

1— *• 

nNODE 

Vdd 

1— ► 

nvdd 

GND 

»—► 

ngnd 

Gnd 

ngnd 

drain 

t—¥ 

drain p 

node 

nNODE 

Vdd 

1— ► 

nvdd 

GND 

t— ► 

ngnd 

Gnd 

1— ► 

ngnd 

where 

node  :  :=  letter _nuniber_specialcharacter-Cletter_nujnber_8pecialcharacter} 
letter.nunber.specialcharacter  ;:=  letter  I  number  I  specialcharacter 
letter  ::=  upper_ca3e_letter  I  lower_case_letter 

and 

nHODE  ::=  n{ [underline] upper_case_letter_number> 
upper_ca3e_letter_number  ::=  upper_ca3e_letter  I  number 

The  set  specialcharacter  =  is  not  necessarily  a  complete  one  since 

magic  allows  labels  to  consist  of  a  large  number  of  different  special  symbols.  The  process  node  i— > 
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nNODE  drops  specialcharacter  and  translates  lower_case_letter  to  upper_case_letter.  The 
mapping  to  upper  case  letters  is  necessary  to  overcome  the  case  sensitivity  of  magic  and  Prolog 
when  generating  case-insensitive  VHDL  code. 
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rV.  A  Formal  Approach  to  Logic  Extraction 


The  extraction  process  is  a  method  of  proving  and  determining  the  existence  of  higher  level 
constructs  from  existing  lower-level  ones.  By  seeing  a  relation  between  component  definitions  and 
extraction  rules,  we  may  demonstrate  that  the  extraction  process  is  a  form  of  hardware- verification. 
In  fact,  the  highest  level  Prolog  rule  may  also  be  the  final  goal  to  be  achieved  in  an  extraction  process 
whereby  only  one  component  is  left  over  after  the  entire  extraction  process  has  run  its  course. 

Past  attempts  at  logic  extraction  have  failed  in  their  expression  of  the  essence  of  logic  extrac¬ 
tion.  Ensuring  that  certain  properties  (i.e.,  protecting  local  and  global  connectivity^)  exist  has  not 
not  been  addressed.  Had  a  formal  approach  to  logic  extraction  been  previously  attempted,  these 
properties  may  have  been  discovered. 

A  formal  definition  of  logic  extraction  will  be  presented  in  terms  of  logic-programming.  Af¬ 
terwards,  the  important  properties  of  a  component’s  description  as  they  relate  to  VHDL  will  be 
proved.  Finally,  properties  concerning  correctness,  completeness,  and  guaranteed  termination  will 
be  presented. 

Defining  Lists 

As  a  matter  of  convenience,  a  logic-programming  representation  in  Prolog  is  used  to  describe 
the  logic  extraction  system.  Using  Prolog  is  proper  for  describing  formal  methods  and  executing 
them  (Wing  90b:  15).  Therefore,  developing  a  unique  synteix  and  semantics  for  the  logic  extrac¬ 
tion  system  is  unnecessary.  The  structures  that  are  used  are  assumed  to  be  finite.  The  various 
components  to  be  used  for  logic  extraction  will  be  described  first. 

A  property  called  not^onnected{signalsa,signalse)  was  stated  previously  in  Chapter  3.  Re¬ 
iterating  the  definition  for  this  property  we  have, 


’  The  discussion  on  local  and  global  connectivity  is  in  Chapter  3. 
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not_connected(sj3na/sa,s23fnaise)  <=  None  of  the  signals  of  signalsa  may  be  a 
member  of  signals^-  Every  signal  of  signalsa  is  unique. 

Prior  to  presenting  a  Prolog  definition  for  not_coQnected/2  the  representation  for  signalsa 
signalse  should  be  described. 

Previously,  signals^  was  described  as  the  signals  of  the  port  and  signalsa  was  described  as 
the  signals  of  the  architecture.  To  make  signalsa  and  signalsf  useful  to  Prolog,  we  will  choose  a 
list  representation  for  both.  Furthermore,  each  signal  of  signalsa  and  signalse  will  be  a  Prolog 
atom^.  In  Prolog,  not_connected/2  may  be  expressed  as 

not_connected( [Signal  I ResetOfSignalsA] .SignalsE) 
not .member (Signal, ResetOfSignalsA) . 
not .member (Signal.SignalsE) , 
not.connected(ResetOfSignalsA.SignalsE) . 
not.connectedC [] ,_) . 

On  the  surface,  it  appears  that  notjconnected/2  is  satisfactory;  however,  an  additional 
stipulation  exists  requiring  that  each  signal  of  signalsa  and  signalse  be  a  Prolog  atom.  The  Prolog 
program  not  .connected/ 2  does  not  guarantee  anything  is  done  to  protect  this  original  stipulation. 
This  being  the  case,  there  is  no  guarantee  that  not.connected/2  will  do  what  it  is  intended  to 
do. 

At  this  point,  there  are  some  desired  properties  of  a  Prolog  program,  V,  that  should  be 
determinable.  These  properties  include  correctness  and  completeness  with  respect  to  the  in¬ 
tended  meaning,  Ai.  The  meaning  of  V,  M('P),  “is  the  set  of  ground  unit  goals  deducible  from 
V”  (Sterl  86:15,82-83).  T^us,  V  is  correct  if  M(P)  C  M.  Further,  V  is  complete  if  Ad  C  M(P). 
Finally,  P  is  correct  and  complete  if  Ad  =  M{P). 

Correctness  and  completeness  are  not  the  only  properties  of  P  that  are  of  interest.  We  also 

wish  to  be  able  to  determine  whether  P  terminates.  For  this  property,  a  termination  domain 

sign&l  in  VHDL  has  a  name  that  corresponds  to  the  meaning  of  atom  in  Prolog.  The  only  difference  is  that 
Prolog  is  case-sensitive;  whereas,  VHDL  is  case-insensitive. 


31 


of  V  must  be  defined.  “A  termination  domain  of  a  program  V  is  a,  domain  V  such  that  every 
computation  of  V  on  every  goal  in  V  terminates.”  (Sterl  86:83)  Further,  a  “domain  is  a  set  of 
goals,  not  necessarily  ground,  closed  under  the  instance  relation.”  (Sterl  86:83)  Finally,  “A  is  an 
instance  of  B  if  there  is  a  substitution  6  such  that  A  =  B9”  (Sterl  86:5) 

As  an  illustration  to  what  is  meant  by  a  termination  domain  P,  consider  the  Prolog  program 
for  list /I. 

list(  [] ) . 

list ([HIT])  listCT). 

The  termination  domain  for  list/1  is  represented  by 
P(ij(  to  include  the  goal  listfX).  Having  listfX)  in  Vmt 
X  would  be  in  however,  the  goal 

?-  list(X). 

results  in  an  infinite  number  of  solutions. 

In  order  to  implement  list/1,  some  restriction  on  V’i,t  must  be  adopted.  This  has  the  effect 
of  rendering  the  program  list/1  fragile.  Tail-recursive  programs  that  have  the  same  form  of  list/1 
require  special  handling.  Consider  the  following  “general”  structure  for  a  Prolog  program  similar 
to  list /I 


We  would  like  the  termination  domain 
would  mean  that  every  instantiation  of 


c(.Pi....,_P„.[]). 
c{Pu...,Po,[Head\Tail])  :- 
goali, 

goalm, 

c{SubPi, . .  .,SuhPo,Tail). 
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where  o  is  the  number  of  parameters  passed  to  the  program  and  m  is  the  number  of  goals  in  the 
clause  body  of  the  program.  A  goal  goali  may  be  defined  to  restrict  the  form  [Head\Tai{]  may 
take  so  as  to  guarantee  a  larger  termination  domain. 

A  restriction  on  the  structure  of  the  list  is  added  to  list /I  to  ensure  termination  over  a  larger 
V.  For  this  purpose  we  will  define  a  meaning  Aiatomjitt,  atomJist/l,  as  a  definition  for  the  list 
structure  to  be  used. 

atom_list(Z/tst)  Either  List  is  empty  or  each  element  of  List  is  an  atom. 

In  Prolog,  the  program  Vatomjiat  appears  as 

atom_li8t( [] ) . 
atom_liat( [HaadiTail] ) 
atOB(H«ad) , 
atOB.listCTail) . 

The  Prolog  program  ’PoiomJi**  makes  use  of  the  built-in  Prolog  function  atom/1.  Anything  meeting 
the  requirements  of  atomJist/1  will  either  be  the  empty  list  []  or  a  list  whose  elements  are  atoms, 
and  every  list  comprising  only  of  atoms  will  meet  the  requirements  of  atomJist/l.  Further, 
atom_list/l  will  terminate  for  anything  supplied  to  it  as  a  proper  Prolog  parameter  under  the 
eissumption  that  finite  structures  are  used. 

A  list  conforming  to  atom_list/l  will  either  be  □  or  be  in  the  form  [en,en-i, . . .  ,ei]  where 
each  e,  ,  1  <  i  <  n,  is  an  atom.  For  the  case  of  atom-list ([]),  we  find  that  the  Prolog  program 
'E’atomjitt  is  consistent  because  it  is  satisfied  by  Q.  For  the  case  of  [cn,  e„_i, . . . ,  ei]  where  each 
fit  1  ^  's  atom  we  have  the  following.  If  we  assert  the  goal,  atomJis<([e„,e„_i, . .  .,ei]), 

we  find  the  first  clause  is  not  satisfiable.  However,  the  second  clause  is  satisfiable.  Performing  an 
expansion  on  the  second  clause  of  atom-list/1 
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a<om_/is<([e„|[e„_i,...,ei]]) 

atom{e„), 

atomJist([e„_i, . .  .,ei]). 

Assuming  atomJist{[en-\,  ■  ■  ■,«!])  true  and  knowing  that  atom{e„)  is  also  true  we  can  see  that 
through  induction,  a<omJis<([e„,  e„_i, . . .  ,ci])  is  accepted  by  Vatomjin-  Therefore,  Matomjist  C 

A/  (T^ator.ijist)- 

To  show  that  VatomJin  is  correct,  first  consider  the  base  case  of  atomJist ( [] ) .  This  is 
acceptable  to  Vatomjist-  Assuming  that  atom_Iist(X)  is  asserted,  through  unification  the  result 
is  still  only  atom_list([]).  Nothing  else  is  acceptable  to  the  first  clause  of  atomJist/l.  Assume 
now  that  for  [cn ,  e„_ i , . . . ,  e i]  some  is  not  an  atom  and  that  atomJ»st([e„_i , . . . ,  ei])  succeeds. 
Thii.  would  mean  that  a<om(e,)  is  true  which  would  be  a  contradiction.  Thus,  M {Vatomjist)  C 
Maiomjist  showing  that  the  program  Vatomjist  is  correct  and  complete. 

By  adding  atom/1  to  form  Vatomjist  we  have  increased  the  previous  termination  domain 
Viist-  The  termination  domain  Vatomjist  may  now  include  any  acceptable  Prolog  structure.  In 
order  to  show  that  the  program  Vatomjist  terminates  for  Vatomjist  we  first  consider  an  empty 
list  [].  In  the  case  of  the  empty  list,  the  first  clause  of  atom-list/1  is  satisfied.  Attempting  to 
satisfy  the  second  clause  results  in  failure  and  terminates  the  execution  of  atomJist/l.  In  the 
case  of  an  acceptable  list  of  size  greater  than  an  empty  we  have  [e„,  e„_i, . . . ,  ci].  The  second 
clause  of  atomJist/1  is  tail  recursive  on  a  list  that  decreeises  in  size  of  one  with  each  invocation  of 
atomJist/1.  The  head  starts  with  a  list  n  elements  long.  It  then  invokes  itself  with  a  list  of  size 
n  —  1  until  the  empty  list,  []  is  left  which  is  terminated  through  the  first  clause  of  atom-list/1. 

For  some  list  failing  to  conform  to  atomJist/l,  the  case  of  a  list  [en,c„_i, . .  .,ei]  is  consid¬ 
ered  where  some  e,  is  not  an  atom.  This  case  may  occur  where  Cj  is  a  variable,  list,  or  compound 
structure.  For  e^,  atomJist/1  would  fail  at  its  (n  —  i)  -b  1  invocation.  Since  no  other  clauses  of 
atom-list  exist  that  might  accept  e,,  the  n  —  i  invocation  fails.  All  invocations  up  to  the  n  —  i 
invocation  also  fail  and  terminate. 
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The  program  Vatomjist  can  be  used  as  a  type-checking  routine  to  guarantee  conformance  of  a 
list  to  the  structure  defined  by  atomJist/l.  This  guarantee  is  very  important  in  that  all  programs 
whose  termination  domain  is  restricted  to  those  structures  defined  by  atomJist/1  may  be  used 
after  atom_list/l  with  the  guarantee  that  the  structure  used  is  within  their  termination  domain. 
Prolog  programs,  Vc,  of  the  form, 


c{Pi,...,Po,[Head\Tail]) 

goah, 

goalm, 

c(SubPi,...,SubPo,Tail). 

fall  into  this  category  provided  goali goalm  can  be  guaranteed  to  terminate. 

The  original  Prolog  program  for  not_connected/2  can  be  rewritten  to  use  atom_list/l. 


not.connectedfSignalsA.SignalsE) 
atom.list (Signals!) , 
atom.listCSignalsE) , 
not_connected_sub(SignalsA , SignalsE) . 

not_connecte<l_sub(  []  ,_)  . 

not_connecte<l_sub( [Signal  I  Signals!] .SignalsE)  :  - 
not .rnembor (Signal, Signals!) , 
not .member (Signal .SignalsE) , 
not .connect  ed.sub ( S ignal s! , S ignal sE ) . 


The  program  atomjist/l  is  used  as  a  type-checking  mechanism  to  ensure  that  parameters  passed 
to  not^onnected/2  are  in  an  acceptable  form.  Without  atomJist/1,  notjconnected/2  would 
have  to  have  its  termination  domain  restricted.  The  Prolog  program  not^onnected.sub/2  is  of 
the  form  described  by  the  program  Vc-  The  termination  domain  2>noi.connec«ed_»u4  is  guaranteed 
by  atomJist/l,  therefore,  we  can  be  eissured  that  it  will  terminate  provided  not  .member/ 2 
terminates.  All  that  is  left  is  to  define  not-member{Signal,  SignalList). 

The  property,  not.member{Signal ,  SignalList),  may  be  defined  in  the  following  manner. 
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not.inein.heT(Signal,  SignalList)  <=  Signal  i*  not  a  member  of  Signal  List. 


The  foil'^wing  is  a  Prolog  definition  for  not  jmember(Signal,  SignalList). 


not_memb«r(_, [] ) . 
not .member (lode, [Head I Tail] ) 
lode  \==  Head, 
not _member(Iode, Tail) . 


The  Prolog  program  not_connected.sub/2  falls  within  the  form  of  Ve.  When  used  within 
not_connected.sub/2  its  termination  domain  is  also  restricted  by  atomJist/1.  The  Prolog  pro¬ 
gram  not.member/2  can  be  shown  to  be  correct  and  complete  in  the  same  manner  as  atomJist/1. 

Finally,  to  ensure  that  each  component  of  a  logic  extraction  rule  is  unique,  the  location 
information  from  the  layout  specification  is  used.  The  location  information  is  usually  in  cartesian 
coordinates  in  magic  and  will  be  assumed  so.  Further,  the  coordinates  will  be  integers.  A  collection 
of  logic  programs  to  ensure  uniqueness  is  shown  below. 


coordinate_list(  □ ) . 

coordinate. list( [[X,Y] I RestOf Coordinates]) 
integer (X) , 
integer(Y) , 

coordinate.list(RestOf Coordinates) . 

unique. component ( [] ) . 
unique. component ( [ [X , Y] I  Tail] )  : - 
not.memberC [X , Y] ,Tail) , 
unique.component(Tail) . 


The  logic  program  coordinate Jist/1  is  constructed  in  the  same  fashion  as  atomdist/1.  The 
logic  program  coordinate  Jist/1  provides  a  type-checking  mechanism  for  unique.component/1 
thereby  ensuring  termination.  The  logic  program  notjnember  also  provides  additional  service 
without  changing  its  meaning. 
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Template  for  Logic  Extraction 


In  this  section,  the  general  template  for  defining  a  logic  extraction  rule  is  presented.  In 
keeping  with  the  description  of  a  structural  VHDL  description  given  earlier,  the  logic  extraction 
rule  will  ensure  the  outlined  properties  are  kept.  However,  the  procedural  aspects  of  Prolog  must 
also  be  considered  so  that  extraction  may  be  performed  in  an  automated  fashion.  Accordingly,  six 
procedural  steps  are  performed  in  the  order  indicated. 

1.  Identify  the  component  from  its  lower-level  components. 

2.  Ensure  that  the  identified  lower-level  components  are  unique. 

3.  Check  that  the  values  of  internal  nodes  do  not  match  other  nodes. 

4.  Delete  the  lower-level  components  from  the  component  netlist. 

5.  Add  the  newly  found  component  to  the  component  netlist. 

6.  Check  to  see  if  there  are  more  lower-level  components. 

Step  1  must  occur  first,  step  two  must  occur  second,  step  three  must  occur  third,  and  step  6  must 
occur  last;  however,  the  order  of  steps  4  and  5  is  not  important. 

The  general  template  for  forming  a  Prolog  extraction  rule  is: 
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head 

matching. goali. 


matching. goaln, 

coordinateJist([[A’i,  Yi], . . . ,  [A"„,  Vn]]), 
unique_component([[A’i,  Vi], . . . ,  [Xn,  ^n]]), 

not_connected(Si</na/sa .  Signals^), 

retract.goali, 


retract.goaln, 

t\nd.aLnoma\yJist(head{argumentJist),SignalSa), 

BsseTta.(head(argument.list)), 

fail. 

head. 

Each  of  the  coordinates  used  by  coordinateJist/l  and  unique^omponent/1  are  derived  from 
each  of  the  matching. goali,  where  1  <  »  <  n.  A  discussion  of  find_anomaly_list/2  is  provided 
later  in  this  chapter. 

Currently,  the  logic  extraction  process  is  divided  into  two  parts.  The  first  part,  called  Level-1, 
is  a  collection  of  rules  for  translating  transistors  of  a  particular  technology  to  logical  connponents. 
The  second  part,  called  Level-N,  is  automatically  generated  (Dukes  91b)  from  VHDL  descriptions 
using  vArfLparser  (Reint  90)  to  translate  VHDL  descriptions  into  Prolog  logic  extraction  rules.  A 
Level- 1  rule-set  for  C'  tOS  and  a  Level- 1  rule-set  for  the  Vitesse  GaAs  process  have  been  developed. 
The  Level- 1  rule-set  for  the  Vitesse  GaAs  process  heis  not  been  extensively  tested.  The  CMOS 
Level- 1  rule-set  contains  rules  for  extracting  inverters,  transmission  gates,  clocked  inverters,  N- 
input  lAID  gates,  N-input  lOR  gates,  and  three  types  of  EXCLUSIVE-OR/EXCLUSIVE-IOR  gates. 
An  additional  rule  for  D-latches  is  also  included. 


Definitions  for  Using  CMOS  Level-1  Rules 


The  level- 1  rules  have  to  be  generated  by  hand,  though  it  is  possible  (but  not  desirable) 
to  use  vhdl2ges  (Dukes  91b)  to  generate  level-1  rules  from  a  structural  VHDL  description  using 
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transistor-type  components.  Since  the  drain  and  source  of  a  CMOS  transistor  are  interchangeable 
in  their  abstract  view,  some  additional  definitions  are  adopted  to  accommoflate  the  abstract  view. 
In  this  section,  an  explanation  and  examples  of  how  Prolog  handles  abstraction  are  presented.  For 
the  representation  of  transistor- facts,  we  adopt  the  following  definition.' 

Definition  1  p{G,  D,  S,  W,  L,X,  V)  is  a  predicate  that  describes  a  p-type  MOS  transistor  with  a 
gate  G,  drain  D,  source  S,  channel  width  W,  channel  length  L,  x-location  X,  and  y-location  Y . 

Definition  2  n{G,  D,  S,  W,  L,X,  Y)  is  a  predicate  that  describes  an  n-type  MOS  transistor  with 
a  gate  G,  drain  D,  source  5,  channel  width  W,  channel  length  L,  x-location  X,  and  y-location  Y. 

The  arity  (number  of  arguments)  of  seven  for  both  the  p  and  n  predicates  assumes  that  the  phys¬ 
ical  bulk  (or  substrate)  connection  of  the  MOS  transistor  is  biased  correctly.  Furthermore,  the 
description  adopted  is  for  p-type  and  n-type  enhancement  mode  MOS  transistors.  Typical  p-type 
and  n-type  MOS  transistors  in  Prolog  appear  as 


pCnIKPUT , nvdd , nOUTPUT .3,6, 1254 , 387) . 
p(nADDII,nA_IllPUT,nA_SELECT,3,6,39887,-3091) . 
n (nIMPUT , ngnd , nOUTPUT ,3,6,1260,387). 

In  the  physical  sense,  the  actual  drain  and  source  are  determined  by  the  biasing  of  the 
device.  In  the  abstract  sense  (i.e.,  magic  and  extract),  the  drain  and  source  are  freely  interchanged. 
Implementations  of  the  p-type  and  n-type  transistors  in  MOS  layout  freely  interchange  the  drain  and 
source  (Weste  85).  In  order  to  express  this  abstract  aspect  and  to  suppress  information  concerning 
length  and  width,  some  further  definitions  are  adopted. 

Definition  3  The  predicate  ‘ptrans’  is  defined  in  terms  of  the  predicate  ‘p’  by  the  implication 
VG,  D.  S,  X,  Y  [(p(G,  D,  S _ A',  V)  V  p(G,  5,  D.  _,  _,  X,  T))  ptrans{G,  D,  S,  X,  T )]. 

Definition  4  The  predicate  ‘ntrans’  is  defined  in  terms  of  the  predicate  ‘n’  by  the  implication 
VG.  D.  5,  A',  y  [(n(G,  D,  S,., .,  A',  T)  V  rj(G,  5,  D,.,  _,  X,  F))  =>  ntrans{G,  D,  5,  A',  V')]. 

The  underscore  indicates  unnecessary  information.  The  Prolog  rules  to  describe  Definitions  3  and 
4  are 
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ptr2ais(G,D,S,X,Y) 

p(G,D.S._._,X,Y). 

ptr2ms(G,D,S,X,Y) 

p(G,S,D,_,_,X,Y). 

ntrans(G,D,S,X,Y) 

n(G.D.S,_,_,X,Y). 

ntran8(G,D,S,X,Y) 

n(G.S.D._,_.X.Y). 


Assuming  that  ptrans/5  and  ntrans/B  exist  in  a  file  called  trcuis.pro  on  a  UNIX  system 
and  that  Quintus  Prolog  is  also  installed  on  the  same  system,  ptrans/B  and  ntrans/S  may  be 
loaded  into  Prolog  in  the  following  manner. 


y.  prolog 

Quintus  Prolog  Release  2.2  (Sun-3,  Unix  3.2) 

Copyright  (C)  1987,  Quintus  Computer  Systems,  Inc.  All  rights  reserved. 
1310  Villa  Street,  Mountain  View,  California  (415)  965-7700 

I  ?-  compile( C'trans .pro’] ) . 

[compiling  /people/dukes/class/trans.pro. . .] 

[trans.pro  compiled  0.267  sec  564  bytes] 

yes 

I  ?- 


The  system  prompt  is  '/,.  The  Prolog  prompt  is  I  ?-  .  The  file,  trans.pro,  was  lo-»ded  into 
Prolog  using  the  Quintus  Prolog  procedure  called  compile/1.  The  Prolog  function,  compile/1, 
compiles  the  contents  of  the  file,  trans.pro,  into  the  current  Prolog  session. 

Assume  the  following  transistor  netlist  exists  in  a  UNIX  file  called  intrans.pro. 


p (nlHPUT , nvdd , nOUTPUT ,3,6,1254,387). 
p (nADDI* , nA.IIPUT , nA.SELECT ,3,6, 39887 , -3091 ) . 
n (nIMPUT , ngnd , nOUTPUT ,3,6,1260,387). 


The  transistor  information  would  be  read  into  Prolog  in  the  following  manner. 
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I  ?-  [ ’ intrans . pro ’ ] . 

[consulting  /people/duXes/class/intrans.pro. . .] 
[intrans. pro  consulted  0.100  sec  S64  bytes] 

yes 

I  ?- 


All  of  tlie  p-type  transistors  may  be  listed  by  querying  Prolog  in  the  following  manner. 

I  ?-  p(G.D.S.M.L.X.Y). 

G  =  nIMPUT, 

D  =  nvdd, 

S  =  nOUTPUT, 

W  =  3. 

L  =  6. 

X  =  1254, 

Y  =  387  ; 

G  =  nADDIH, 

D  =  nX.IHPUT, 

S  =  nA.SELECT, 

W  =  3. 

L  =  6. 

X  =  39887, 

Y  =  -3091  ; 

no 

I  ?-  halt. 

[  End  of  Prolog  execution  ] 

•/. 


The  upper  case  letters,  G,  D,  S,  VV,  L,  X,  and  Y,  designate  variables  to  be  satisfied  by  Prolog.  The 
;  (semicolon)  is  used  to  request  further  information  from  the  transistor  database  that  satisfies  the 
request.  Otherwi.se,  a  carriage  return  not  preceded  by  a  ;  would  have  terminated  the  search.  The 
halt/0  predicate  tells  Prolog  to  terminate  and  return  to  the  system  prompt. 

Assume  now  that  the  transistor  netlist  consists  of  the  following  components. 


p  (nmPUT ,  nvdd ,  nOUTPUT  ,3,6,1254,387). 
p (nlKSTATE , nKOTIXSTATE , nvdd ,3,6,1254,387). 
pCnADDIM , nA.IIPUT . nA.SELECT ,3,6, 39887 , -309 1 ) . 
n (nllPUT , ngnd , nOUTPUT ,3,6,1260,387). 
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Assume  also  that  we  are  interested  in  finding  transistors  with  nvdd  on  either  the  drain  or  source 
of  a  p-type  transistor.  The  objective  may  be  accomplished  in  one  of  two  ways.  The  first  method  is 
to  express  two  queries  to  Prolog  using 


I  ?-  p(G,nvdd,S,W,L,X.Y)  ;  pfG.D.nvdd.W.L.X.Y) . 


In  the  above  example,  the  ;  is  used  to  logically  OR  the  two  queries.  The  result  of  the  two  queries 
is  displayed  below. 


*/.  Prolog 

Quintus  Prolog  Release  2.4  (VAX,  Ultrix  2.0-2. 2) 

Copyright  (C)  1988,  Quintus  Computer  Systems,  Inc.  All  rights  reserved. 
1310  Villa  Street,  Mountain  View,  California  (415)  965-7700 

I  ?-  [’ intrans .pro’] . 

[consulting  /people/dukes/class/intrans .pro. . .] 

[intrans. pro  consulted  0.167  sec  880  bytes] 

yes 

I  ?-  p(G,nvdd,S,W,L,X,Y)  ;  p(G,D,nvdd,W,L,X,Y) . 

G  =  nIHPUT, 

S  =  nOUTPUT, 

W  =  3, 

L  =  6, 

X  =  1254, 

Y  =  387, 

D  =  _149  ; 

G  =  nIMSTATE, 

S  =  _55, 

W  =  3, 

L  =  6, 

X  =  1254, 

Y  =  387, 

D  =  nlOTIMSTATE  ; 

no 

I  ?- 


42 


However,  the  Prolog  rules  stated  in  ptrans/S  will  accomplish  the  same  task,  as  shown  in  the 
following; 


*/,  Prolog 

Quintus  Prolog  Release  2.2  (Sun-3,  Unix  3.2) 

Copyright  (C)  1987,  Quintus  Computer  Systems,  Inc.  All  rights  reserved. 
1310  Villa  Street,  Mountain  Vies,  California  (415)  965-7700 

I  ?-  compile( ['trans.pro'] ) . 

[compiling  /people/dukes/class/trans.pro. . .] 

[trans.pro  compiled  0.250  sec  564  bytes) 

yes 

I  ?-  [’intrcuis.pro’]  . 

[consulting  /people/dukes/class/intrans.pro. . .) 

[intrems.pro  consulted  0.100  sec  688  bytes] 

yes 

I  ?-  ptrans(G,nvdd,S,X,Y) . 

G  =  input, 

S  =  output, 

X  =  1254, 

Y  =  387  ; 

G  =  instate, 

S  =  notinstate, 

X  =  1254, 

Y  =  387  ; 

no 

I  ?- 


This  example  demonstrates  that  rules  using  transistors  may  not  be  concerned  with  the  interchange- 
ability  of  the  drain  and  source.  Assuming  that  circuit  function,  not  timing,  is  of  primary  interest, 
unnecessary  information  (e.g.,  gate  width  and  length)  may  be  eeisily  dropped  when  performing 
extraction. 


Guaranteeing  Termination  for  Logic  Extraction 

For  the  purpose  of  this  discussion,  the  following  representation  will  be  used. 
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•  LE{Case)  will  represent  the  Case  under  consideration  for  logic  extraction. 

•  Pterminate  will  represent  the  property  of  termination  being  true. 

Further,  there  are  only  a  finite  number  of  facts  in  the  facts  data  base. 

Several  cases  will  be  considered.  In  all  cases,  m  and  n  will  represent  natural  numbers  excluding 
zero.  The  first  case  addresses  the  possibility  of  replacement  of  m  components  by  n  where  m  <  n. 
The  second  case  addresses  the  replacement  of  m  components  by  n  components  where  m  =  n. 
Finally,  the  last  case  addresses  the  replacement  of  m  components  by  n  components  where  m  >  n. 
For  the  discussion  of  logic  extraction,  not_connected/2  and  find_anomaly/2  are  assumed  to 
terminate. 

Case  1.  The  first  case  to  discuss  deals  with  the  replacement  of  m  components  by  n  compo¬ 
nents  where  m  <  n.  What  we  want  to  show  is  that 


LE{tn  <  n)  =>  Pterminate- 


Logic  extraction  rules  constructed  through  GES  only  assert  a  single  component.  Thus,  n  =  1; 
however,  n  >  m  by  our  original  assumption  and  m  >  1  meaning  that  n  can  never  be  1.  Therefore, 
LE{m  <  n)  is  false  and  the  assertion  for  case  1  is  trivially  proven. 


Case  2.  The  second  caise  to  discuss  concerns  the  replacement  of  m  components  by  n  com¬ 
ponents  where  m  =  n  or 

LE{m  =  n)  => 

Pterminate- 

There  are  two  subcases  to  be  proven.  These  cases  are^ 


((m  >  I)  A  (n  >  1))  F  LE{fTl  —  n)  Pterminate 


^  A  discu.ssion  on  the  form  P  I-  o  is  in  Appendix  E. 
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and 


((m  —  1)  A  (n  —  1))  h  LEijn  —  n)  ^  Pterminatt- 
Rewriting  the  first  subcase,  we  have 

((m  >  1)  A  (n  >  1))  h  ((m  >  1)  A  (n  >  1))  =>  {LE(m  =  n)  =►  Purminau)- 

From  Case  1  we  know  that  n  has  to  be  1.  Therefore,  (n  >  1)  is  false  and  this  subcase  is  true. 

For  the  second  subcase  of 

((m  =  1)  A  (fl  =  1))  H  LiE{tTI  —  n)  Pterminate 

the  value  for  m  is  valid  as  well  as  n.  Thus,  the  extraction  rule  must  be  examined.  The  following  is 
a  representation  of  a  logic  extraction  for  the  case  where  the  component  being  matched  is  the  same 
as  the  component  being  asserted  on  the  component  data  base. 

c 

c(Pi,...,Po), 

not_connected([  ],[Pi, . .  • ,  Po]), 
retract{c{Pi, .  ■  •,  Po)), 
find_anomalyJist(c(Pi, . . . ,  P<.),0). 
asserta(c(Pi , . . .,  Po)), 
fail. 
c. 

Both  not_connectc<i/2  and  find.^nomalyJist/2  terminate  immediately  due  to  □  ■  The  remain¬ 
der  requires  an  understanding  of  fact  matching  and  asserta/l. 

In  Prolog,  matching  of  facts  starts  at  the  head  of  a  facts  data  base.  Upon  each  retry,  the 
succeeding  fact  is  looked  up.  Prolog  does  not  return  to  a  preceding  fact.  In  this  fashion,  a  data  base 
of  facts  has  a  head,  a  tail,  and  a  progression  from  head  to  tail.  The  Prolog  procedure  asserta/l 
places  a  fact  before  the  head  of  a  fact  data  base.  By  modifying  the  facts  data  base  in  this  fashion, 
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a  newly  asserted  fact  will  not  cause  infinite  backtracking  through  the  facts  data  base  since  it  is 
considered  a  preceding  fact.  Furthermore,  the  facts  data  base  is  assumed  to  be  finite.  Therefore, 
by  using  asserta/1  we  are  guaranteed  termination. 

For  the  case  where  the  matching  goal  and  the  fact  being  asserted  are  not  the  same,  the  process 
is  trivial.  Each  time  a  goal  is  matched,  a  new  component  of  a  different  name  is  asserted.  This 
process  continues  until  all  facts  are  retracted.  The  rule  then  terminates. 


Case  3.  The  last  case  to  discuss  concerns  the  replacement  of  m  components  by  n  components 
where  m  >  n  or 


LE{m  >  n)  ^ 

terminate- 


From  case  1,  we  know  that  n  must  be  1.  Since  m  >  1  by  substitution,  we  see  that  the  number  c 
components  is  decreasing  rather  than  ever  increasing.  At  worst,  the  logic  extraction  process  will 
continue  until  only  one  component  is  left. 


Design  Rule  Checking 

The  extraction  methodology  previously  described  has  only  been  concerned  with  extracting 
normal  circuits.  However,  we  cannot  assume  that  the  circuit  to  be  extracted  is  free  from  design 
errors.  Since  errors  may  exist  in  a  design,  we  must  be  prepared  to  find  them.  These  errors  occur 
because  the  external  interconnections  of  a  component  are  configured  in  an  inconsistent  condition. 
In  this  section,  the  problem  of  identifying  these  errors  will  be  discussed. 

Identifying  External  Design  Errors  The  CMOS  designs  described  earlier  were  based  on 
a  design  style  of  a  particular  designer  or  group  of  designers.  Just  as  CMOS  designs  are  based  on 
a  design  style,  so  too  are  design  errors.  A  few  of  the  types  of  design  errors  possible  are  shown  in 
Figure  9.  It  is  important  to  point  out  that  the  following  circuits  are  considered  to  be  errors  because 
they  are  not  normally  used  in  the  design  of  a  VLSI  circuit. 


46 


vdd 

? 

vdd 

? 

vdd 

? 

vdd 

O  .out 

vdd 

n  drain 

drain 

in_J 

‘”-L 

rC 

V 

V 

V 

gnd 

lout 

gnd 

gnd 

1 

source 

T,  source 
gnd 

(a) 

(b) 

(c) 

(d) 

(e) 

if) 

Figure  9.  Some  Transistor- Level  Design  Errors. 

Subfigures  a  and  b  of  Figure  9  typify  a  dangerous  circuit.  This  type  of  design  error  may 
result  from  one  of  several  actions  on  the  part  of  the  layout  system  used.  If  plowing  or  some  other 
form  of  circuit  rearrangement  is  being  performed,  it  is  possible  to  connect  the  terminals  of  the 
transistor  in  the  fashion  shown.  During  layout  in  magic,  routing  over  subcells  with  metal  layers 
that  accidentally  contact  the  same  layer  of  lower  subcells  may  also  cause  this  problem.  In  either 
case,  the  result  is  a  circuit  that,  when  turned  on,  will  cause  a  short-circuit  between  Vdd  and  GND. 

The  physical  nature  of  such  a  circuit  is  not  the  only  concern  in  Subfigures  a  and  b  of  Figure  9. 
Assuming  for  discussion  that  we  were  only  concerned  with  showing 

Implementation  =>  Specification 

the  result  of  Subfigures  a  and  b  could  lead  to  an  invalid  conclusion.  Essentially,  the  resulting 
equation  from  such  an  error  might  be 

FALSE  =>  Specification. 

The  specific  problem  of  connecting  V’dd  and  GND  at  the  transistor  level  in  HOL  has  been  raised  by 
(Gupta  91:20).  The  problem  is  generally  referred  to  as  “false  implies  everything”  (Camil  86:22).  A 


false  antecedent  can  lead  the  naive  verification  method  to  conclude  an  implementation  meets  a  spec¬ 
ification.  Therefore,  checking  for  such  errors  can  reduce  occurrences  where  improper  conclusions 
about  hardware  might  be  reached. 

The  circuits  in  subfigures  c  and  d  of  Figure  9  are  a  little  less  destructive  than  the  circuits 
discussed  earlier.  However,  they  may  indicate  design  errors.  These  circuits  may  be  easily  replaced 
by  a  metal  line  connected  to  Vdd  for  subfigure  c  or  GND  for  subfigure  d.  Even  though  these  circuits 
may  be  caused  by  the  problems  indicated  for  subfigures  a  and  b,  they  may  also  be  the  result  of 
tying  inputs  to  arrays  of  standard  cells  high  or  low.  Subfigures  e  and  f  of  Figure  9  demonstrate 
another  possible  design  error.  As  with  the  circuits  in  subfigures  c  and  d,  their  creation  may  be 
accidental  or  incidental.  The  following  “error”  definition  is  offered. 

Definition  El  'iln,  Out,  Drain,  Source, 

1.  ptrans(In,vdd,gnd)  is  an  error; 

2.  ntrans(ln,vdd,gnd)  is  an  error; 

3.  ptrans(gnd,vdd,Out)  is  an  error; 

4.  ntrans(vdd,Out,gnd)  is  an  error; 

5.  ptrans( vdd, Drain, Source)  is  an  error; 

6.  ntrans(gnd, Drain, Source)  is  an  error. 

Recognition  of  design  flaws  is  not  limited  to  single  transistors.  Erroneous  designs  consisting 
of  groups  of  transistors  may  also  occur.  Figures  10  provides  examples  of  designs  that  may  be 
considered  design  errors.  For  these  structures,  another  “error”  definition  may  be  considered. 


Definition  E2  VPy,  Ng.  In.  Out, 

1.  invZ(Pg,Pg,ln,Out)  is  an  error; 

2.  invZ(Pg,Ng,ln,In)  is  an  error; 

3.  tgatc(Pg,Pg,In,Out)  is  an  error; 

4.  tgate(Pg.Ng,In,In)  is  an  error; 

•').  inv(In,In)  is  an  error. 
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Figure  10.  Some  Gate-Level  Design  Errors. 

The  list  of  errors  included  in  Definitions  El  and  E2  is  not  complete.  For  some  designs,  some  of 
the  enumerated  errors  may  not  be  errors  at  all.  Therefore,  definitions  for  design  errors  are  declared 
within  the  domain  of  the  design  style  under  consideration. 

Prolog  Implementation  for  Identifying  External  Design  Errors  This  section  de¬ 
scribes  two  methods  for  using  Prolog  to  identify  design  errors.  The  first  method  described  is  an 
interactive  one  where  the  user  provides  statements  to  be  satisfied  by  Prolog  from  the  component 
database.  The  second  method  described  allows  the  user  to  specify  a  list  of  Prolog  rules  that  may 
be  stored  in  a  file  and  executed  at  a  later  time. 

Definitions  El  and  E2  designate  certain  component  configurations  to  be  erroneous.  Using 
Prolog  interactively,  these  errors  may  be  identified  easily.  The  following  is  a  demonstration  of  how 
the  component  database  is  examined  for  the  occurrence  of  the  first  type  of  error  in  Definition  El. 
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I  ?-  ptrajis(In,nvdd,ngnd,X,Y) . 
In  =  n20_024_14A_BAR, 

X  =  5722, 

Y  =  141  ; 

In  =  n20_024_13A_BAR, 

X  =  6722, 

Y  =  506  ; 

In  =  n20_024_12A_BAR, 

X  =  5722, 

Y  =  798  ; 

In  =  n20_024_llA_BAR, 

X  =  6722, 

Y  =  1017 


Notice  the  use  of  the  two  additional  fields,  X  and  Y.  These  fields  contain  location  information  that 
may  be  used  to  find  the  errant  components.  Through  the  use  of  Definition  3,  we  were  able  to  ask 
Prolog  to  identify  those  transistors  that  satisfied  one  of  the  design  error  types  in  Definition  El.  We 
may  also  perform  the  same  query  for  higher  level  components  as  shown  below. 

I  ?-  tgate(Pg,Ig,In,In,X,Y). 
no 

1  ?-  tgate(Pg,Pg,In,Out,X,Y) . 

Pg  =  nl2_0typeIIId_4X0R, 

In  =  nl2_0typ6lIId_4C0UTl, 

Out  =  nl2_0typ«IIIb_16C0UTl, 

X  =  -306, 

Y  =  97  ; 

Pg  =  nl2_0typ«IIIb_15X0R, 

In  =  nl2_0typaIIIb_16C0UTl, 

Out  -  nl2_0typ«IIIa_14C0UTl, 

X  =  -306, 

Y  =  170  ; 

Pg  =  nl2_0typ6lIIc_9X0R, 

In  =  nl2_0typeIIIc_9C0UTl , 

Out  =  nl2_0typeIIIb_14C0UTl, 

X  =  -290, 

Y  =  316 


In  the  previous  example,  the  component  database  wm  queried  for  the  existence  of  any  trans¬ 
mission  gates  that  met  condition  4  of  Definition  E2.  In  this  case,  no  transmission  gates  were  found. 
However,  when  Prolog  was  queried  for  the  existence  of  transmission  gates  that  violated  condition 
3  of  Definition  E2,  several  instances  were  found  and  reported. 
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Design  errors  may  also  be  found  through  the  establishment  of  Prolog  rules  prior  to  perform¬ 
ing  duplicate  transistor  reduction  and  extraction  in  the  case  of  Definition  El.  Furthermore,  the 
extraction  process  may  be  performed  after  extraction  using  Level- 1  rules  to  identify  components 
that  satisfy  to  Definition  E2.  The  following  is  an  example  of  a  rule  used  to  find  a  design  error 
identified  in  Definition  El. 

i*  Error  type  1  ♦/ 

find_ error 

ptransfG.nvdd.ngnd.X.Y) , 

sriteC'Bad  trass,  ') .*rite(ptraiis(G,nvdd,ngnd,X,Y)) , 
vrite(':  removed’} >nl> 
remove_p(G.nvdd,ngnd) , 
fail. 

/*  Error  type  2  •/ 

find_error 

ntransfG.nvdd.ngnd.X.Y) , 

vriteC’Bad  trans,  ’) ,Brite(ntran8(G,nvdd,ngnd,X,Y)) , 
vriteC’:  removed' ) ,nl , 
remove_n(G,nvdd,ngnd) , 
lail. 

/*  Error  type  3  */ 

lind.error 

ptransCngnd.nvdd.S.X.Y) , 

write ( 'Straight  wire,  ’ ) ,write(ptraii8(ngnd,nvdd,S,X,Y)) , 
writeC’:  removed’)  ,iil, 
remove_p(ngnd,nvdd,S) , 
lail. 

/♦  Error  type  4  ♦/ 

lind_error 

ntrans (nvdd , ngnd , S , X , Y) , 

write ( 'Straight  wire,  ’) ,write(ntran8(nvdd,ngnd,S,X,Y)) , 
writeC’:  removed’) ,nl, 
remove.n (nvdd, ngnd, S) , 
lail. 

/♦  Error  type  6  ♦/ 

lind_error 

ptrans(nvdd,A,B,X,Y) , 

write(’Open  connection,  ’ ) ,write(ptrans(nvdd,A,B,X,Y)) , 
writeC’:  removed ’), nl , 
remove_p(nvdd,A,B) , 
lail. 

/♦  Error  type  6  ♦/ 

lind_error 

ntrans (ngnd, A, B,X,Y) , 

writeC’Open  connection,  ’ ) ,write(ntran8(ngnd,A,B,X,Y)) , 
writeC’:  removed’ ) ,nl, 
remove_n(ngnd, A,B) , 
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fail. 

f ind_ error . 


Notice  that  lind_error.  is  listed  laist.  This  is  to  provide  a  successful  outcome  when  all  of  the 
previous  clauses  fail. 


The  following  Prolog  rules  are  used  to  identify  design  errors  that  conform  to  Definition  E2. 

f ind_more_errors  :  - 

clk_inv(P,P,In,Out,X,Y) , 

uriteC ’Screwy  clk_inv,  ’) ,Brite(clk_inv(P,P,In,Out,X,Y)) , 
writeC’:  removed’) ,nl. 
retract(clk_inv(P,P,In,Out ,X,Y)) , 
fail. 

f ind_more_errors 

clk_inv(Pg,Ig.Bad,Bad.X,Y) . 

writeC ’Oscillating  clk.inv,  ’) .write(clk_inv(Pg,lg,Bad,Bad,X,Y)) , 

*rite(’:  removed’) .nl, 

retract (clk_inv(Pg, Ig, Bad, Bad, X,Y)) , 

fail. 

f ind.more.errors 

tgate(P,P,In,Out,X,Y) , 

writef ’Screwy  tgate,  ') ,write(tgate(P,P,In,Out,X,Y)) , 

writeC’:  removed’ ) ,nl, 

retract (tgate(P, P, In, Out ,X,Y)) , 

fail. 

f ind_more_error8 

tgate(Pg,Ig,Bad,Bad,X,Y) , 

write ( ’Worthless  tgate,  ’ ) ,write(tgate(Pg,Bg,Bad,Bad,X,Y)) , 

write(’:  removed’) ,nl, 

retract (tgate (Pg , Ig , Bad , Bad , X , Y) ) , 

fail. 

f ind_more_errors 
inv(Bad,Bad,X,Y), 

write ( ’Oscillating  inv,  ’ ) ,write(inv(Bad,Bad,X,Y)) , 
write(’:  removed ’), nl , 
retract(inv(Bad,Bad,X,Y)) , 
fail . 

f ind_more_errors . 


Identifying  Internal  Design  Errors  The  Prolog  rule,  find^nonialy_list/2  is  used  to 
identify  “global”'*  connectivity  errors  such  as  the  one  shown  in  Figure  7.  Identifying  this  class  of 
error  is  important,  since  connections  that  violate  the  component  boundary  implied  by  a  structural 

*The  discussion  of  global  and  local  connectivity  is  in  Chapter  3. 
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VHDL  description  change  the  behavior  of  the  component  to  be  extracted.  The  following  Prolog 
program  is  a  definition  for  identifying  this  problem. 


lind_anomaly_list(_,  □) . 
lind_anoBialy_li8t(Comp, [HodalRest] ) 
find.anocalyf Comp, lode) , 
lind_anomaly_liat(Comp,Rest) . 


The  Prolog  rule  calls  upon  a  series  of  clauses  under  find_anoinaly/2  that  compares  one  of 
the  internal  nodes  of  the  component  being  extracted  to  the  external  connections  of  the  all  other 
components  in  the  component  database.  An  example  of  how  findjinomaly/2  is  defined  to  examine 
transistors  and  a  transmission  gate  is  the  following. 


f ind_anomaly(Comp,lod6) 

(ptrana(Iode,_,_,X,Y) ; 
ptran8(_,Iod6,_,X,Y) ; 
ntran8(Mod«,_,_,X,Y) ; 
ntran8(_,Iod«,_,X,Y)) , 

write( ’Failure  extracting  component  ’) ,write(Comp) , 
write( ’ . ’ ) ,nl ,write( ’  Internal  node,  ’) ,Brite(Iode) , 
«rite(’,  connected  to  a  transistor  at  X:’), 

Hrite(X) ,write(’,  Y:’),write(Y) , write ( ’ . ’ ) ,nl . 
f ind_anomaly(Comp,Rode) 

(tgate(Iode,_,_,_,X,Y) ; 
tgate(_,Iode,_,_,X,Y) ; 
tgate(_,_,Iode,_,X,Y) ; 
tgate(_,_,_,lode,X,Y)) , 

sriteC 'Failure  extracting  component  ’ ) ,Hrite(Comp) , 
writeC ' . ’ ) ,nl ,write( '  Internal  node,  ’ ) ,write(lode) , 
writeC’,  connected  to  a  tgate  at  X;'), 
write(X) ,write(’,  Y:’),write(Y) , write ( ’ . ’ ) ,nl . 
f  ind_^Ulomaly 


The  Prolog  program  find-anomaIy/2  is  set  up  to  produce  warning  messages  to  the  designer  and 
continue  hunting  for  other  possible  connectivity  problems.  Further,  findjanoinaly/2  is  set  to 
succeed  in  this  case  so  that  errors  for  other  components  may  be  found.  Use  of  a  !  ,lail  could  have 
been  used  to  force  failure  upon  the  first  encounter  if  desired. 
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A  separate  find.anomaly/2  is  generated  for  each  type  of  component  that  can  exist  in  the 
component  data  base.  Additional  find_anomaly/2  clauses  are  generated  automatically  by  vhdl2ges 
(Dukes  91b)  for  each  component  that  can  be  generated  on  the  component  data  base  by  an  extraction 
rule. 

The  Prolog  program  find^nomaly_lIst/2  corresponds  to  the  form  of  Vg.  The  list  passed 
to  find^nomaly  Jist /2  is  guaranteed  to  be  in  the  termination  domain  Vg  by  atom_list/l  used 
in  not_connected/2.  Further,  find_anomaly/2  executes  only  while  component-facts  of  the  type 
being  searched  exist  in  the  component  database.  Thus,  we  can  be  reasonably  certain  that 
find_anomalyJist/2  will  always  terminate. 
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V.  Delay  Models  for  VHDL 


Timing  information  used  for  hardware  design  may  be  viewed  from  several  perspectives.  The 
physical  representation  of  the  design  (e.g.  mask  layout  description)  can  provide  close  approxima¬ 
tions  of  the  actual  resistive  and  capacitive  loading  encountered  in  a  design.  At  a  more  abstract 
level  of  the  hardware  design,  a  VHDL  model  may  be  used  to  predict  hardware  timing  from  a  di¬ 
rect  or  indirect  perspective.  The  discussion  that  follows  presents  three  methods  of  accomplishing 
pin-to-pin  critical  path  analysis.  The  type  of  critical  path  analysis  examined  in  this  research  per¬ 
forms  the  process  of  extracting  pin-to-pin  critical  p?ths  in  two  steps.  A  calculation  of  propagation 
delays  through  the  lowest-level  components  is  performed  in  the  first  step.  The  second  step  involves 
summing  delays  from  inputs  to  outputs  for  all  possible  critical  paths. 

For  instance,  the  physical  layout  description  may  be  viewed  as  the  lowest  level  perspective 
in  critical  path  analysis.  Extracting  pin-to-pin  critical  paths  from  a  layout  description  using  logic 
extraction  occurs  in  the  following  manner. 

1.  Propagation  values  are  calculated  from  known  capacitive  and  resistive  loading  in  the  circuit. 

2.  Delays  are  summed  along  paths  from  input  pins  to  output  pins. 

Calculating  Delays  from  Layout 

Shown  in  f'igure  11  is  a  simple  model  of  a  CMOS  inverter  used  to  calculate  delay^.  The 
figure  represents  the  resistive  and  capacitive  elements  that  would  be  encountered.  The  elements  in 
the  circuit  are  Rp  for  the  resistance  through  the  channel  of  the  p-type  MOS  transistor,  R„  for  the 
resistance  through  the  channel  of  the  n-type  MOS  transistor,  Rc  for  the  “lumped^”  resistance  of  the 
output  node,  C/,  for  the  "lumped^”  capacitance  of  the  output  node,  C]  . .  .Cn  for  the  capacitance"* 

^This  model  was  chosen  to  demonstrate  one  method  for  incorporating  delay  calculations  into  the  extraction 
process  of  GES. 

^the  resistance  as  romputed  on  a  node  by  magic's  extract 

^the  sum  of  the  capacitances  between  the  output  node  and  all  other  nodes  reported  by  ext28im 

^  Since  exiSstm  does  not  produce  gate  capacitances,  a  gate  capacitance  is  also  computed  from  the  existing  tran¬ 
sistors  in  the  transistor  database  in  GFyS. 
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on  every  MOS  gate  connected  to  the  output  node,  and  Vq  for  the  voltage  between  the  output  node 
and  GND. 


Figure  11.  A  Simple  Delay  Model. 

From  Figure  11,  two  delay  models  may  be  constructed.  The  general  equation  used  for  prop¬ 
agation  delay  is® 

^  =  (7) 

For  the  case  where  the  p-type  MOS  transistor  of  the  circuit  is  turned  on,  the  n-type  MOS  transistor 
of  the  circuit  is  off,  and  Vo  is  equal  to  ground,  the  propagation  delay  may  be  described  by 

n 

t  =  (R,  +  R,,XCl  +  ^Q).  (8) 

i  =  l 

Likewise,  for  the  case  where  the  n-type  MOS  transistor  of  the  circuit  is  turned  on,  the  p-type  MOS 
transistor  of  the  circuit  is  off,  and  Vq  is  equal  to  Vdd,  the  propagation  delay  may  be  described  by 

r» 

r  =  (/?„-(- fit )(Ct -I- ^C,).  (9) 

1=1 

If  we  consider  the  CMOS  inverter  cus  a  degenerate  case  of  the  NOR-gate  and  the  NAND- 
gate,  propagation  delays  may  also  be  calculated  by  the  appropriate  parallel  and  series  formulas  for 
the  p-type  and  n-type  MOS  transistor  networks  of  both  types  of  gates.  Calculating  propagation 

^This  model  for  computing  delays  is  typical  of  one  method  shown  in  the  literature  (Ouste  84) 
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delays  based  on  this  model  appears  valid,  provided  the  output  node  terminates  only  on  gates  of 
MOS  transistors.  Should  pass  transistor  logic  exist  in  the  circuit,  a  different  view  must  be  adopted. 

For  pass-transistor  logic,  the  following  practice  is  adopted.  A  pass-transistor  path  is  one 
which  follows  along  the  drain  to  source  of  a  p-type  or  n-type  MOS  transistor  without  a  termination 
to  Vdd  or  GND.  The  total  load  resistance,  Ri,  is  determined  from  the  appropriate  parallel  and 
series  computations  of  resistances  along  all  pass-transistor  paths  connected  to  the  output  node. 
Furthermore,  all  capacitances  along  all  pass-transistor  paths  connected  to  the  output  node  are 
summed.  Essentially,  a  worst-case  calculation  of  possible  loading  is  performed  by  assuming  all  peiss 
transistors  are  in  a  conducting  state.  A  worst-case  calculation  is  necessary  for  conducting  critical 
path  analysis. 

Determining  Propagation  Delay  in  VHDL 

There  are  three  methods  that  may  be  used  to  determine  propagation  delay  from  a  VHDL 
model.  The  first  method  uses  the  timing  information  explicitly  stated  in  the  VHDL  model  through 
the  signal  assignment  statement.  The  second  method  calculates  the  timing  information  from  the 
loading  on  a  particular  input.  The  third  method  combines  the  delay  based  on  loading  and  the 
explicitly  stated  delay  in  the  VHDL  model. 

Delay  Model  Specified  in  VHDL  As  indicated  in  Figure  12,  delays  are  specified  by  the 
VHDL  model  for  all  components  regardless  of  the  output  drive.  In  this  case,  a  specified  delay  on 
a  component  in  VHDL  implies  the  drive  required  by  that  physical  component  to  meet  that  delay. 
Propagation  delays  along  paths  are  then  determined  in  a  way  similar  to  step  two  for  the  physical 
layout  description. 

Delay  Model  for  Loading  in  VHDL  Shown  in  Figure  13  is  a  model  for  calculating  delay 
of  a  component  output.  The  function 


In 

Out 

' 

Comp 

r-Li 

• 

— 

Ddi 

where  Ddi  =  delay 

delay  is  fixed  regardless  of  N 

Figure  12.  Delays  Specified  in  Description. 


delayir  -  f{[Lx,.  -,LN\,Ddr)  (10) 

returns  a  delay  value  based  on  the  loading  of  other  components  being  driven  by  the  output  and  an 
internal  drive  capacity,  D.  Once  the  delays  are  calculated  for  all  components,  delays  are  summed 
along  paths  from  input  pins  to  output  pins  in  a  fashion  similar  to  the  second  step  for  critical  path 
analysis  of  physical  layout. 
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where  Ddr  =  drive 
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delaydV  - 

■-  f{\Lu...,LN],Ddr) 

Figure  13.  Delays  Calculated  from  Fanout. 

It  is  not  obvious  how  the  fanout  for  a  signal  may  be  calculated.  The  information  may  be 
gathered  by  flattening  a  VHDL  model  using  a  Prolog  routine  called  flatten.  The  Prolog  routine 
converts  a  hierarchical  VHDL  model  to  a  gate-level  component  netlist.  Propagation  delays  may 
then  be  calculated  by  determining  the  number  of  inputs  being  driven  by  a  signal.  The  search  is  easy 
to  perform  and  each  component  has  a  propagation  delay  calculated  through  this  method.  At  this 
point,  logic  extraction  may  be  conducted  through  a  customized  GES  routine,  performing  pin-to-pin 
critical  path  analysis. 
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Hybrid  Delay  Model  in  VHDL  The  hybrid  delay  model  combines  the  two  previous 
models.  A  hybrid  delay  equation  may  be  constructed  as  follows. 

delayhy  =  delayer  +  Dm  (11) 

Like  the  delay  model  fnr  loading  in  VHDL,  delay  values  for  all  components  must  be  calculated 
first,  assigning  each  a  delays-  Then  a  delayhy  is  calculated  for  each  component  based  on  Eq  11. 
Afterwards,  propagation  delays  are  determined  in  a  manner  similar  to  step  two  for  the  physical 
layout  description. 
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VI.  Critical  Path  Analysis 


Knowing  that  a  layout  specification  matches  a  structural  specification  component-by-compo- 
nent  and  connection-by-connection  is  not  sufficient  to  guarantee  equivalence  between  both  struc¬ 
tural  specification  and  a  layout  specification.  Other  properties,  e.g.,  power  requirements,  circuit 
delays,  and  circuit  reliability,  are  important  to  consider  in  addition  to  circuit  function.  If  a  cir¬ 
cuit  does  not  meet  a  timing  constraint  specified  in  its  structural  specification,  then  it  is  useless 
regardless  if  it  is  funtionally  equivalent  to  its  structural  specification. 

Presented  in  this  chapter  is  one  approach  to  performing  pin-to-pin  critical  path  analysis  of 
a  circuit  within  the  logic  extraction  process.  We  will  show  how  logic  extraction  limits  the  circuit 
size  under  consideration  for  pin-to-pin  critical  path  analysis  and  prunes  many  noncritical  paths 
early.  Through  the  process  of  pruning,  pin-to-pin  critical  path  analysis  of  very  large  circuits  may 
be  pc-isible. 

Though  this  chapter  focuses  on  pin-to-pin  critical  path  analysis,  other  properties  of  a  circuit 
may  h  ^  examined.  VV'e  hope  that  the  discussion  on  pin-to-pin  critical  path  analysis  here  will  provide 
insig:;t  as  to  how  other  properties  may  be  extracted  within  logic  extraction. 

Consideration  of  Feedback  in  Critical  Path  Analysis 

The  contrib\»tion  of  feedback  loops  to  pin-to-pin  critical  analysis  is  considered  here  before 
prese  iting  the  definitions  for  structures  used  in  the  pin-to-pin  critical  path  analysis.  Figure  14  is  a 
Huffi  an  model  (Hayes  88- 108- 109)  for  a  typical  circuit.  CN  represents  the  combinational  circuit 
network  and  L  represents  the  latching  or  memory  circuit.  The  output  of  the  circuit  depends  upon 
the  inputs  and  the  present  state  values  of  L.  In  a  stable  circuit,  the  delays  from  input  to  output  in 
the  CN  do  not  include  the  feedback  paths.  Thtis,  the  delay  of  the  combinational  circuit  is  actually 
within  the  CN  portion  of  the  model.  The  asynchronous  cycle  time  may  be  computed  by  “breaking” 
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the  feedback  paths  in  the  VHDl,  model  and  extracting  the  circuit  with  a  new  VHDL  model,  thus 


adding  the  CN  and  L  critical  paths  together. 


Figure  14.  Huffman  Model. 


Extracting  Critical  Paths 

Every  component  above  the  transistor  level  in  GES  contains  a  set*  of  paths.  A  path,  V,  is  a 
pair,  [L,  D],  where  is  an  edge-bounded  acyclic  path  (EAP)  and  D  is  the  propagation  delay  of 
L.  L  is  an  ordered  collection  of  nodes  where  the  head  is  the  first  node  in  the  EAP  anu  the  last  is 
the  last  node  in  the  EAP.  All  of  the  nodes  in  L  describe  a  path  through  a  circuit.  For  the  purpose 
of  constructing  pin-to-pin  critical  paths  through  a  circuit,  £"  is  a  set  of  input  and  output  nodes  for 
the  component  being  extracted,  which  is  a  subset  of  all  the  nodes  in  the  circuit. 


Path  Generation  Without  Feedback 


The  following  are  definitions  for  terms  and  functions  used  to  form  the  extraction  of  critical 
paths  during  the  extraction  process  in  GES.  For  notation,  a  preceding  lower  case  letter  on  a  label 


‘Sets  and  lists  in  the  context  of  this  discussion  have  different  meanings,  though  both  are  represented  through 
lists  in  Prolog.  In  the  ca.se  of  a  set,  the  conventional  meaning  e»s  an  unordered  collection  of  unique  objects  prevails. 
A  list  is  considered  to  be  an  ordered  collection  of  objects. 

^  L  is  used  here  since  the  structure  confomrs  to  list/1. 
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designates  an  atom,  a  preceding  upper  case  letter  on  a  label  designates  a  variable,  and  a  preceding 
underscore^  designates  a  “don’t  care.” 

Definition  1  A  node  is  on  interconnection  label  in  a  circuit.  For  notation,  a  node  is  represented 
by  n. 

Definition  2  dn  EAP  is  on  ordered  sequence  of  nodes.  An  EAP  is  constructed  as  [rii, . .  .,n„], 
where  m  >2  and  ni  ^  rim. 

Using  the  symbol  |  as  a  list  constructor,  an  EAP  may  be  constructed  as  [ni|[n2|[n3| . . .  [nm|[]]  •  •  •]]]■ 
The  node  r»i  is  called  the  head,  the  list  of  nodes  following  ni  is  called  the  tail,  and  is  called  the 
last.  For  notational  convenience,  the  head  of  L  may  be  referred  to  as  head(L),  the  tail  referred  to  as 
tail(/T,  aiul  the  last  referred  to  as  last(L).  Functionally,  the  head,  tail,  and  l2ist  may  be  represented 
a.s  the  following. 


h€ad([ni,.  •,«„]) 

taiH[ni,n2 . n„]) 

•  os/(  [«!,...,«„]) 


(n2,...,nm] 


Definition  3  The  predicate,  mcmbrr(n,  L),  is  true  when  n  P  L  and  false  otherwise. 


rnf  m6fr(  A’,  [jV|_L])  — ►  true 

T7icT7j6fr(  A’,  [_A’1L])  —  m€mber[N,L) 


In  Prolog,  member  riiay  be  written  as  the  following. 


'In  Prolog,  an  iinHerscore  clpsignates  a  "don't  care."  In  order  to  preserve  t!  »  meaning  of  a  variable  location  and 
avoid  singleton  variable  warnings  in  Quintus  F’rolog  (Quint  88),  this  notation  was  adopted. 
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member (I , [I I _L] ) . 


memberd,  [_M|L]  )  member (I.L)  . 


Definition  4  The  predicate,  append(Li,L2,L3)  is  true  when  Li  =  [ni,  . . .  .fim],  L2  =  [nm+i,  •  -  - 
)  ^m+p])  and  L3  =  [ni ,  .  .  .  ,  rim+i  i  -  -  •  >  ^m+p)* 


In  Prolog,  the  append  function  may  be  written  as  follows. 


append([HlLl] .L2, CHIL3])  append(Ll .L2,L3) . 
appendC  □  ,L,L) . 


Let  Li,  L2,  ■  ■ Li  be  EAPs,  Hi  —  head(Li),Ti  =  tast{Li)  and  £■  a  set  of  input  and  output 
nodes  for  the  component  being  extracted  which  is  a  subset  of  all  the  nodes  in  the  circuit. 

Definition  5  jotn(Li,  L2,  L3)  is  true  iff 

/.  memberfHi,  E), 

2.  Ti  =  H2. 

3.  memberfl’i,  E)  ts  false, 

4-  memberfj'2.  Li)  ts  false, 

5.  R2  =  latl(L2), 

6.  and  appendfLi ,  R2,  L3). 


In  Prolog,  the  join  function''  may  be  written  as  the  following® 


^DifTerpnre  lists  (Bratk  86;  1 92)  may  be  used  to  increase  the  efficiency  of  the  operations  shown. 

^In  some  Prolog  implementations  (Quint  88).  the  not/1  function  does  not  exist.  In  this  context,  the  not/1 
function  is  assumed  to  be  defined  as 

not(Goal)  call(Goal) , ! ,fall . 
not(  J  . 
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join(CHl|Rl] , [T1IR2] .E.L3) 

aemberCHl.E),  last(Rl,Tl),  last(R2,T2),  not (member (T1 ,E)) . 
not (member (T2, [H1|R1])),  append ( [HI I Rl] ,R2,L3). 

For  convenience,  the  symbol  will  be  used  to  denote  the  join  operation  in  the  following 
manner. 

[L3  =  Li  ★  L2]  =  [join(Li,  L2,  L3)].  (12) 

EAPs  may  only  be  constructed  using  the  join  predicate.  In  essence,  the  join  operation  may  be 
thought  of  as  an  EAP  extension  function.  This  being  the  case,  we  may  show  the  following. 

Lemma  1  An  EAP,  L,  with  head(L)  ^  E,  will  have  only  two  nodes  (m  =  2). 

Proof 

By  Definition  5,  only  EAPs  with  head{L)  6  E  may  be  extended.  Therefore,  all  EAPs 
with  m  >  2  must  have  their  head(L)  €  E  leaving  lists  with  head{L)  g?  E  with  only 
m  =  2. 

Theorem  1  Let  L  be  an  m  node  EAP  where  2  <  m  and  I  <  i  <  m,  1  <  j  <  m,  and  i  ^  j. 
Vn  £  L,  if  Hi  =  nj  then  L  is  not  a  valid  EAP. 

Proof 


base  case:  Assume  m  =  2.  Then  L  —  [ni,n2]-  Assume  ni  =  n2.  This  is  not  consistent 
with  Definition  2.  Therefore,  ni  ^  n2. 

hypothesis:  Assume  m  >  2.  Then  L  =  [ni,...,nm].  ni  ^  n„,  by  Definition  2.  By 
Lemma  1,  we  know  that  nj  £  E.  Furthermore,  we  assume  that  L  contains  no  feedback 
loops. 

induction:  Lm+i  =  [ni,  ■  .Um+i]  and  =  [nm,nm+i].  We  need  to  show  that 

f'm  +  l  —  Lm  Lnj,m  +  I  ■ 

The  EAP  Lm+1  cannot  exist  oi  be  formed  if  €  E  by  Definition  5.  Thus  ^  E 
and  by  Lemma  1,  the  EAP,  Lm,m^  1 ,  must  have  only  two  nodes.  For  the  operation  to 
be  valid.  Um+i  ^  Lm  hy  Definition  5  thereby  avoiding  a  feedback  loop. 
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From  Theorem  1,  it  is  evident  that  EAPs  are  constructed  free  of  feedback  loops  through 
the  “join”  function.  Figure  15  shows  how  the  join  function  works  initially.  As  noted  previously, 
feedback  loops  do  not  contribute  to  the  critical  path  of  CN  and  may  be  eliminated.  This  being  the 
case,  the  resulting  EPAs  constructed  from  a  finite  collection  of  EPAs  will  be  finite  and  the  number 
of  possible  paths,  P,  spanning  a  component  from  input  to  output  will  be  restricted  by  a  finite  set 
E.  Some  bounds  on  the  process  of  forming  pin-to-pin  critical  paths  may  be  realized. 
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Figure  15.  Initial  Application  of  the  join  Function. 

Figure  16  shows  how  the  join  function  works  at  some  point  after  the  initial  join  function 
is  used.  Examining  L2  in  Figure  16,  it  appears  that  cycles  might  exist  within  L3  after  the  join 
operation  is  performed;  however,  the  nodes  forming  the  EAP  between  Y  and  Z  are  the  interior 
nodes  of  the  subcomponent  to  which  the  path  Lj  belongs.  Essentially,  L2  may  be  considered  to 
have  only  Y  and  Z  as  shown  in  Figure  15.  Thus,  Theorem  1  and  Lemma  1  still  hold  regardless  of 
the  level  of  hierarchy. 


■nsB 

wmviwm 

Figure  16.  General  Application  of  the  join  Function. 


Within  an  extraction  rule,  there  may  exist  more  than  one  path  for  each  subcomponent.  Before 
any  path  manipulation  is  performed  for  a  component,  the  subcomponents  and  interconnections  are 
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checked  by  the  extraction.  Afterwards,  a  list  of  the  component’s  external  signals  is  constructed. 
All  of  the  paths  from  the  subcomponents  are  appended  together  into  a  list  of  paths.  The  list  of 
paths  and  external  signals  is  then  passed  to  a  Prolog  function. 

At  the  top  level,  the  algorithm  for  finding  the  pin-to-pin  critical  paths  is  as  follows. 

initial  conditions:  a  list,  E,  of  external  nodes  and  a  list  of  paths. 

1.  Generate  all  possible  new  paths. 

2.  Eliminate  any  path  for  which  the  head  or  tail  of  the  list  is  not  in  E. 

3.  Eliminate  paths  that  are  not  pin-to-pin  critical  paths. 

The  algorithm  for  generating  new  paths  is  the  following. 

initial  conditions:  a  list,  E,  of  external  nodes  and  a  list  of  paths. 

1.  Perform  the  join  operation  on  all  lists  of  paths  and  add  their  respective  delays. 

2.  Eliminate  paths  that  were  used  to  construct  new  paths  where  the  heads  of  their 
EAPs  are  in  E. 

3.  Repeat  until  no  new  paths  are  generated. 

Once  the  extraction  process  has  completed,  another  routine  may  be  used  to  generate  a  structural 
VHDL  description.  The  VHDL  description  is  currently  generated  with  pin-to-pin  critical  path 
information  as  comments. 

Efficiency 

Assume  a  component  with  I  inputs,  O  outputs,  and  M  nodes.  Initially,  all  EAPs  within 
the  component  will  contain  two  nodes.  In  the  worst  case,  all  nodes  might  be  interconnected.  An 
enumeration  of  a  worst-case  initial  condition  is  .shown  in  Table  1.  The  indicates  no  entry 
allowed®.  From  Table  1  the  only  lists  that  do  not  exist  are  those  along  the  diagonal.  This  being 
the  case,  the  worst-case  initial  number  of  EAPs  is  —  m  or  O(m^). 

*  Definition  2  in  the  previous  section 
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Now  we  consider  the  worst  case  number  of  EAPs  that  might  exist  between  two  nodes.  For 
the  time  being,  consider  only  the  upper-right  half  of  Table  1  and  an  EAP  with  fij  as  an  input  and 
Tim  as  an  output.  From  the  table  and  the  join  function,  the  possible  EAPs  may  be  enumerated  in 
the  following  manner. 


La 

Li 

L2 

La 


[ni,A'?,.. 

[ni,X°,.. 

[ni,A'?,.. 


•  1  A^_2i  f*m] 

•.A“_3,A^_2,n„] 

•  >  ^m-3<  ^m-2<  ”m] 


L 


-  2  _  1 


[ni ,  ^  ,  A^_3,  ^m] 


In  each  f’.AP,  A'j  designates  the  existence,  Xj,  or  nonexistence,  A'j*,  of  its  respective  node,  Hj  -f- 1.  In 
the  case  A']’,  the  corresponding  comma  is  not  considered  to  exist  in  the  EAP.  From  the  enumeration 
of  possible  FAPs  that  may  exist  from  rii  to  rim,  the  order  is 


Table  1.  Initial  EAPs  in  a  Hypothetical  Component 


node 

112 

03 

-  - 

»>1 

* 

[«i.n2} 

[ni,n3] 

[n  1 ,  Htti] 

"2 

(^2,  ni] 

* 

[na.na] 

[n2,nmj 

na 

[na,  «i] 

[n3.n1] 

* 

•  •  [^2i  ^m] 

[flm.  t»il 

[nm.  ”2] 

[nm.ns] 

If  we  include  the  bottom-left  half  of  the  matrix,  the  problem  becomes  more  complex.  Since 
the  interior  nodes  may  now  occur  in  any  order  and  appear  no  more  than  once,  the  complexity  of 
the  problem  is  raised  to  0((2”'“‘)!),  This  upper  bound  is  highly  pessimistic.  Normal  circuits  do 


not  contain  this  high  level  of  interconnectivity.  The  number  of  EAPs  is  further  constrained  by  the 
scope  of  the  extraction  rule. 

Since  the  efficiency  of  the  join  function  is  0((2'”~^)!),  the  join  function  is  highly  unreasonable 
as  a  tool  for  pin-to-pin  critical  path  analysis,  even  for  a  modest  number  of  interconnected  nodes. 
However,  within  the  realm  of  the  GES  extraction  rule,  the  size  of  the  circuit  being  examined  is 
usually  small.  As  a  result,  the  number  of  interconnected  nodes  is  small.  The  hierarchical  nature 
of  VHDL  allows  a  circuit  to  be  viewed  as  a  component  constructed  of  subcomponents  which  are, 
in  turn,  constructed  iiom  subsubcomponents  and  so  forth,  until  the  lowest  level  is  reached.  The 
extraction  system  uses  the  hierarchical  view  of  the  circuit,  working  from  the  lowest  level  toward  the 
highest-level  component  view.  As  a  result  of  the  extraction  process,  a  critical  path  of  a  component 
may  be  thought  of  as  the  construction  of  smaller  critical  paths  through  several  of  its  subcomponents. 
Figure  17  shows  how  a  pin-to-pin  critical  path  is  constructed  from  the  pin-to-pin  critical  paths  of 
its  subcomponents.  Therefore,  it  is  not  necessary  to  carry  along  other  noncritical  paths  within 
subcomponents,  thereby  prunitig  out  many  nodes  that  would  not  contribute  to  the  pin-to-pin 
critical  path  of  the  cotnponent. 


Figure  17.  Critical  Path  Analysis. 
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False  Paths 


Though  a  discussion  of  all  critical  path  analysis  techniques  is  beyond  the  scope  of  this  research, 
it  is  important  to  discuss  one  aspect  of  critical  path  analysis.  The  previous  technique  of  calculating 
a  pin-topin  critical  path  for  a  component  considers  a  full  path  regardless  of  whether  the  path 
through  the  subcomponents  will  contribute  to  the  actual  delay  of  the  component.  This  type  of 
path  is  referred  to  as  a  false  path. 

For  a  purely-combinational  circuit,  this  type  of  problem  may  not  arise;  however,  for  a  se¬ 
quential  circuit  the  result  may  be  different.  Should  a  pin-to-pin  critical  path  be  identified  as  in  the 
previous  section,  there  is  no  guarantee  that  there  is  a  state  in  the  hardware  under  consideration 
that  would  lead  to  the  use  of  the  identified  path. 

To  illustrate  a  false  path,  consider  a  typical  clocked  JK  flip-flop  as  shown  in  Figure  18.  When 
the  ciock  pulse  on  c  is  high,  the  inputs  from  j,  k,  q,  and  notq  are  able  to  propagate  through 
the  first  stage,  but  not  thr  ugh  the  second  stage.  When  the  clock  pulse  on  c  is  low,  values  are 
propagated  through  the  second  stage. 


Figure  18.  Typical  Clocked  JK  Flip-Flop. 
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Assume  that  the  propagation  delay  through  the  first  two  NAND  gates  is  4  nanoseconds  (ns), 
the  delay  through  the  rest  of  the  NAND  gates  is  3  ns,  and  the  delay  through  the  inverter  is  1  ns. 
Knowing  the  delays  through  the  components  of  Figure  18,  a  set  of  paths  may  be  constructed.  The 
paths  are  shown  below. 


[  [[notq.u] .4] ,  [[j,u],4],  [[c.u],4].  [Cc,v],4D,  [[k.vj,4j,  [[q,v].4], 
[[u,h].3],  [[x,w].3],  [[h,x],3],  C[v.x],3].  CCc.notc]  ,  1]  . 

CCw.y],3],  [[notc.y] ,3] ,  [[notc.z] ,3] ,  [[x,z],3], 

C[y.q]|3].  CCnotq.q] ,3] ,  [[q.notq] ,3] ,  C[z,notq],3]  ] 


The  set  of  input  and  output  nodes  for  the  component  is  £7  =  j,  k,  c,  q,  notq  which  we  will  represent 
as  the  following. 


[j .k.c.q.notq] 


After  application  of  the  algorithm  for  finding  the  pin-to-pin  critical  paths,  the  following  set 
of  paths  results  for  the  clocked  JK  flip-flop. 


[  CCnotq,u,w,y,q] , 13] ,  Cfj .u.w.y.q] ,13] ,  [[k, v.x.z.notq] , 13] , 

[[q, v,x,z,notq] , 13] ,  [[j ,u,w,x,z,notq] , 16] ,  [[c,u,B,x,z,notq] ,16] , 
[[c.v,x,w,y,q] ,16] ,  [Ck,v,x,w,y.q] ,16]  ] 


If  stage  1  is  broken  from  stage  2  in  Figure  18,  a  maximum  delay  path  through  stage  1  is  CCj  ,u,b]  ,7]  , 
and  a  maximum  delay  path  through  .stage  2  is  [[v,y,qj  ,6]  ,  A  maximum  delay  path  through  stage 
1  wiii  r  ns  and  a  maximum  delay  path  through  stage  2  will  take  6  ns.  Putting  both  stages  to¬ 
gether  renders  a  maximum  delay  for  the  clocked  JK  flip-flop  of  13  ns;  however,  the  pin-to-pin  critical 
path  analysis  rendered  a  maximum  delay  path  of  [[j  ,u,w,x,z,notq]  ,16]  for  a  maximum  delay 
of  1(5  ns  through  the  clocked  JK  flip-flop.  The  maximum  delay  path  of  [[j  ,u,w,x,z,notq]  ,  16]  is 
never  used  as  a  result  of  the  clock. 
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Therefore,  the  rendered  false  path  would  provide  an  overly  pessimistic  view  of  the  delay  for  a 
given  pin-to-pin  critical  path.  So  the  model  presented  in  the  previous  section  should  be  used  with 
this  caveat.  If  a  more  complicated  model  is  desired,  the  previous  section  should  be  a  guide  on  how 
to  incorporate  other  critical  path  analysis  models  into  the  logic  extraction  process. 
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VII.  Examples  and  Results 


In  this  section,  four  layout  designs  in  magic  will  be  examined.  The  first  is  a  rather  simple 
design  of  a  fabricated  two-phase  clock  generator.  The  second  design  is  an  ALU  that  was  verified 
using  GES  and  fabricated.  The  third  design  is  a  60,000  transistor  design.  The  Icist  design  is  a  larger 
250,000  transistor  design.  In  all  four  examples,  GES  was  used  in  the  layout  process  to  identify 
external  and  internal  design  errors.  The  first  example  demonstrates  the  Design-Rule  Check  (DRC) 
capability  of  GES.  In  the  second  example,  a  design  is  verified  using  only  GES  for  functionality  and 
critical  path  analysis.  The  third  and  fourth  examples  are  used  to  demonstrate  the  performance  of 
GES  on  large  custom  VLSI  chip  designs. 

Clock  Generator 

A  clock  generator  is  an  example  of  a  circuit  that  functions  correctly,  yet  cannot  be  simulated 
by  estm  (Terma  80).  esim  is  a  switch-level  simulator  that  accepts  as  input  a  transistor  netlist 
from  magtc.  The  simulator  state  advances  after  values  on  all  nodes  have  converged  to  a  steady 
state.  Since  the  clock  generator’s  normal  function  is  to  oscillate,  esim  cannot  simulate  the  circuit; 
however,  GES  can  extract  the  logical  composition  of  the  circuit  to  demonstrate  that  the  correct 
components  and  the  correct  connections  exist. 

The  transistors  in  the  transistor  netlist,  generated  from  the  mask  layout  description  using 
eilract.  form  fully  static  CMOS  components.  The  logical  components  were  extracted  from  the 
transistor  netlist.  The  following  is  a  listing  of  the  log  file. 
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I  ?-  ges. 

finished  with  read. 

Capacitor  ptrans (nIZ_CAP2 , n3_ 140_8 , n3_140_8 , 136 , 52) : removed 

Capacitor  ntran8(nIZ_CAPl ,n3_12_115,n3_12_115,9,-42) :removed 

finished  with  find.error. 

finished  inverters. 

finished  tgates. 

finished  clk.inv. 

finished  nand. 

finished  nor. 

finished  f ind_more_error8 . 


There  were  two  capacitors  placed  in  the  circuit  to  vary  clock  frequency  and  duty  cycle.  Both  did 
not  appear  in  the  transistor  netlist  using  mertra  (Terma  86);  however,  they  did  appear  using  extract 
(Calif  86).  The  input  to  GES  used  the  output  from  extract,  thus  the  capacitively  isolated  signals, 
IZ.CAPl  and  IZ_CAP2,  show  up  in  the  report  as  capacitive  transistors.  The  capacitively  isolated 
signals  nlZ.CAPl  and  nIZ_CAP2  were  found  and  removed.  All  other  components  in  the  circuit  were 
successfully  extracted  using  GES. 

GES  produced  a  listing  of  the  components  in  the  clock  generator  and  their  interconnections. 
The  mask  layout  description  of  the  clock  generator  was  verified  to  have  been  generated  correctly 
inasinuch  as  the  components  and  their  interconnections  were  concerned. 

I'o  introduce  a  flaw  into  the  clock  generator  circuit,  the  metal-1  line  for  GND  and  the  metal- 
1  line  output  of  an  inverter  were  shorted  together,  demonstrating  a  possible  human  error  during 
layout.  Figure  19  is  a  circuit  diagram  of  the  normal  and  abnormal  portion  of  the  affected  circuit. 
To  help  make  the  example  more  intert'sting,  a  polysilicon  line  has  also  been  severed.  The  first  fault 
demonstrates  a  stuck-at-0  fault,  whereas  the  second  demonstrates  a  floating  fault  on  one  portion 
of  the  inverter.  In  addition  to  the  external  errors,  an  internal  error  is  introduced  between  a  lOR 
gate  and  an  inverter.  \t  this  point  there  is  a  multiple  fault  in  the  circuit. 

The  following  is  a  log  of  the  Prolog  session  using  GES  on  the  errant  clock  generator  circuit. 
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I  ?-  ges. 

finished  «ith  read. 

Bad  trans  ptrans(n3_12_115,nvdd,ngnd,70,7) :removed 

Straight  wire  ptran8(ngnd,nvdd,n3_44_29,99,8) rremoved 

Capacitor  ptrans (nIZ_CAP2 , ngnd , ngnd ,136,52); removed 

Capacitor  ntrans(nIZ_CAPl ,n3_12_llS,n3_12_115,9,-42) : removed 

Capacitor  ntrans(n3_12_115, ngnd , ngnd ,71,-21): removed 

finished  with  find.error. 

finished  inverters. 

finished  tgates. 

finished  clk_inv. 

finished  nand. 

Failure  extracting  component  nor_gate(n3_72_106, 
n3_340_35.n3_238_103, 155,11 , 1) .  Internal  node, 
n3_314_22,  connected  to  an  inverter  at  X:197,  Y:13. 
finished  nor. 

finished  f ind_more_errors . 


ALU 

riic  aiul  ronsf ruct ion  of  the  ,\Lr  started  with  the  VHDL  design  and  ended  with 

verifn  ation  of  the  layout  description  I  he  steps  in  the  design  of  the  ALU  are  shown  below. 

1  A  Behavioral  VHDL  ilesr  riplion  was  generated. 

A  Structural  \  "Dl,  description  was  generated. 

.$  Both  the  structural  and  behavioral  descriptions  were  simulated  together  and  results  compared, 
t  Corrections  were  made  to  the  structural  description  as  deviations  were  encountered. 
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5.  vhdlSges  was  run  to  generate  a  “customized”  GES  extraction  system  from  the  structural  VHDL 
description  for  the  design. 

6.  The  physical  layout  description  was  generated  by  hand  from  the  transistor  level  up. 

7.  As  each  cell  was  created,  the  “customized”  GES  extraction  system  was  run  to  ensure  conformance 
to  the  structuial  VHDL  description. 

8.  Once  the  entire  ALU  was  completed  and  verified  using  the  “customized”  GES  extraction  system, 
pin-to-pin  critical  path  analysis  was  performed. 

At  no  time  in  the  design  was  a  switch-level  simulation  or  SPICE  simulation  of  the  layout  de¬ 
sign  performed.  During  the  layout  process,  various  errors  in  interconnections  were  caught  by  the 
“customized"  GF^S  extraction  system. 

'I'he  ALU  had  a  4-bit  opcode,  4-bit  operands,  4/8-bit  result,  and  comparator  output.  A  view 
of  the  layout  for  the  ALU  is  shown  in  Figure  20.  The  design  was  primarily  based  on  the  bit-slice 
design  from  (Mano  82:217-228)  with  the  addition  of  a  multiplier.  Less  than  2  man-weeks  were 
rf'ciuired  to  fully  describe  the  design  in  VHDL  and  lay  out  in  magic.  A  total  of  4  integrated-circuit 
chips  were  fabricated  from  MOSIS.  .All  chips  were  tested  with  80,000  test  vectors  in  various  sorted 
and  psuedo-random  sequences  and  were  found  to  be  100%  functionally  correct.  The  pin-to-pin 
critical  path  analysis  reported  a  lO.VtHz  operation  speed  compared  to  the  13.5MHz  actual  speed  of 
t he  chips 

60.000  Transistevr  Design 

GES  was  used  on  a  60.000- 1  ransistor  design  of  a  multiplier  .section  in  a  floating-point  multiplier 
chip  The  statistic/0  function  of  Quintus  Prolog  was  used  to  report  periodic  timing  statistics 
within  the  extraction  process.  These  results  appear  in  Table  2.  Less  than  8  Megabytes  of  memory 
were  required  for  this  design.  The  performance  results  were  collected  from  a  MicroVAX  3600 
running  Ultrix  V3  1  using  Quintus  Prolog.  Three-hundr'“d-eighteen  design  errors  w-^re  found  in  the 
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VLSI  design.  From  Definition  El  (shown  in  Figure  9),  there  were  30  type-1  errors,  36  type-3  errors, 
10  type-4  errors,  10  type-5  errors,  and  120  type-6  errors.  From  Definition  E2  (shown  in  Figure  10), 
there  were  82  type-4  errors. 


Time  to  Perform 

CPU  Time  (min:sec) 

Read  and  Eliminate  Duplicates 

025:40 

Find  Definition  El  Errors 

000:26 

Find  inv 

002:56 

Find  tgates 

683:15 

Find  invZ 

121:32 

Find  nand 

036:30 

Find  nor 

025:21 

Find  Definition  E2  Errors 

000:05 

Find  dff 

000:11 

Write  Component  Netlist 

007:24 

Table  2.  Performance  on  a  60,000-'IVansistor  Design 


From  the  perfoi  'nance  measurement  of  GES  in  Table  2  we  can  make  a  few  observations.  I/O 
for  the  e.xample  had  moderate  impact  on  the  execution  time  of  GES.  Looking  for  errors  in  the  design 
can  be  done  quickly.  This  is  indeed  desirable,  since  a  designer  might  want  to  interact  with  GES  in 
an  attempt  to  find  errors  that  may  exist  within  a  layout  design.  Though  the  timing  statistics  do 
not  represent  many  level-N  components,  extraction  for  other  types  of  components  (e.g.,  half-adders, 
adders,  adder-arrays,  registers)  usually  progresses  quickly.  The  vast  majority  of  extraction  time  is 
usually  spent  with  the  level- 1  rules. 


Performance  on  a  250,000-Transistor  Design 

A  2.50.000  transistor-sized  section  of  a  1,500,000  transistor-sized  design  was  used  to  examine 
t  he  performance  of  the  logic  extraction  rules  when  considering  indexing.  The  inverter,  transmission- 
gate,  and  clocked-inverter  rules  were  used.  The  section  used  was  largely  constructed  of  memory 
cells.  The  platform  used  to  perform  extraction  was  a  MicroVAX  3900  running  Quintus  Prolog 
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V2.4  on  Ultrix  V4.2.  Shown  in  Table  3  are  the  results  of  running  logic  extraction  on  this  250,000 
transistor-sized  design. 


Time  to  Perform 

CPU  Time  (min:sec) 

Memory  (MegaBytes) 

Read  and  Eliminate  Duplicates 

270:25 

24 

Find  Definition  El  Errors 

002:43 

24 

Find  inv 

012:54 

24 

Find  tgates 

028:42 

24 

Find  invZ 

018:12 

24 

Write  Component  Netlist 

032:42 

24 

Table  3.  Execution  Times  of  Indexed  Logic  Extraction  Rules  for  a  250,000  Transistor  Design 


The  CPU  time  for  extracting  inverters,  transmission-gates,  and  clocked  inverters  was  less 
than  an  hour.  From  Table  3,  the  time  to  read  in  the  transistors,  eliminate  duplicates,  and  build  the 
transistor-facts  data  base  took  considerable  CPU  time.  Altogether,  the  process  consumed  6:05:38 
(h:mm:ss)  of  CPU  time.  The  total  CPU  time  required  for  a  60,000  transistor-sized  design  for  the 
same  operation  was  14:01:13.  Indexing  allowed  for  extraction  of  a  design  of  more  than  four  times 
in  size  in  less  than  half  the  time. 
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VIII.  Limitations 


Presently,  there  are  two  types  of  limitations  that  exist  in  using  GES.  The  first  type,  alluded 
to  earlier,  involves  acceptable  VHDL  code.  The  second  type  involves  designs  that  are  not  easily 
extracted.  After  the  discussion  of  the  limitations,  some  suggestions  for  overcoming  these  limitations 
will  be  discussed. 

Currently,  only  structural  VHDL  descriptions  with  signals  of  mode  in  and  out  are  accepted. 
The  modes  buffer  and  inout  cannot  be  handled  while  still  ensuring  correct  critical  path  analysis 
as  described  previously.  There  do  not  appear  to  be  problems  with  signals  of  mode  linkage. 

The  second  limitation  specifically  involves  the  types  of  component  configurations  that  are 
recognized  and  extracted.  Assume  that  an  extraction  rule  exists  for  identifying  an  AND  gate 
formed  from  a  NAND  gate  followed  by  an  inverter.  A  typical  GES  extraction  rule  for  identifying 
this  configuration  is  the  following. 


and_gat«  :  - 

nand_gat«(Ix,Iy ,Iintenn,XO,YO,_) , 
inv( lint era, loutput ,X1 ,Y1 ,_) , 
unique_component( [[XI ,Y1] , [XO.YO]]), 
not_connected( [iintera] , [lx,ly,loutput]) , 
retract(inv(lintera,loutput , 
retract (nand_gate (lx , ly .Iintera 

f ind_anomaly_list(and_gate(lx,l7,loutput ,XO,YO, 1) , [Iintera] ) , 
as  s  er t ( and_gat  e ( lx , ly , loutput , XO , YO , 1 ) ) , 
fail . 
rmd.gate . 


From  the  extraction  rule  and_gate/0,  every  NAND  gate  followed  by  an  inverter  will  be  replaced 
with  an  AND  gate. 


Consider  an  additional  extraction  rule,  halfjidderjrc/0,  constructed  as  follows. 
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halX_adder_cc  : - 

xor_gat«(Ix,Iy ,Isuiii,XO,YO,_)  , 
nand_gat«(Ix,Iy,Icbar,Xl,Yl ,_) , 
invdcbar  .Icaurry  ,X2,Y2,_) , 
unique_component( C[X2,Y2] , [XI ,Y1] , [XO.YO]] ) , 
not_connacted( [Icbar] , [lx.ly ilsum.lcarry]) , 
retract(inv(Hcbaur,Icarry, , 
retract (nand.gat e (Hx , ly , Icbar 
retract (xor_gate (Ix , ly , Isua 

f ind_anomaly_li8t(half_adder_cc(Ix,Iy .Isim.Icarry.XO.YO, 1) , [Icbar] ) , 
assert (half _adder_cc(lx , ly , Isua .Mcarry.XO , YO, 1) ) , 
fail . 

half _adder_cc . 


We  will  use  the  and_gate/0  and  half_adder_cc/0  rules  to  perform  extraction  on  the  following 
components. 


nand_gate(na,nb,ncbar , 1 ,1,1). 
xor_gate(na,nb,nsua, 10, 1 , 1) . 
inv (nebar , ncarry ,1,10,1). 


If  the  half.adder_cc/0  extraction  rule  is  used  before  the  and_gate/0  extraction  rule,  the  following 
will  result. 


half _adder_cc(na,nb,nsua, ncarry ,10,1,1). 


However,  if  the  and_gate/0  extraction  rule  is  used  before  the  half_adder_cc/0  extraction  rule, 
the  following  will  result. 


xor_gat(  (na,nb,nsua, 10,1,1). 
and_gats(na,nb, ncarry, 1,1,1) . 

There  are  three  methods  for  solving  this  problem.  The  first  method  involves  ordering  the 
rules  such  that  the  half-adder _cc/0  extraction  rule  is  called  before  the  and-gate/0  extraction 
rule.  This  prevents  the  and_gate/0  extraction  rule  from  interfering  with  proper  extraction  of  the 
half-adder-Cc/0  extraction  rule  The  next  two  methods  are  interrelated. 
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If  higher-level  structural  VHDL  descriptions  are  not  making  use  of  the  fact  that  an  and^gate 
VHDL  description  exists,  then  the  and_gate  VHDL  description  should  be  eliminated.  However, 
if  it  is  necessary  to  have  an  and_gate  VHDL  description,  ensure  that  ail  higher- level  structural 
VHDL  descriptions  take  advantage  of  the  and_gate  VHDL  description.  This  type  of  recisoning  may 
require  the  designer  to  make  more  prudent  use  of  VHDL-based  models.  However,  the  designer  may 
employ  another  method  of  enriching  the  extraction  rule  set  by  simply  adding  an  additional  VHDL 
description  for  half  adders  using  AND  and  Exclusive-OR  gates. 

The  previously  described  problem  is  not  the  only  case  where  hierarchical  extraction  may 
re(piire  some  manual  intervention.  Some  extraction  rules  might  force  extractions  over  component 
boundaries.  An  exarnph'  of  how  this  might  occur  follows. 

'I'he  previously  defined  extraction  rules,  and_gate/0  and  half-adder jcc/0,  will  be  used. 
A.ssume  a  new  extraction  rule  for  half_addcr/0. 


half .adder 

half .adder.cc (Mx , My , Msum , Mcbar , XO , YO , _ )  , 

inv(Mcbar ,Mcout , XI ,Y1 , 

unique.componentC [[XI , Yl] , [XO.YO]]) , 

not_coimected( [Mcbar] , [Mx.My.Msum.Mcout]) , 

retract ( inv (Mcbar ,Mcout , 

r etract (half .adder _cc(Hx , My , Msum, Mcbatr,.,. ,_)) , 

find_anomaly.list(half_adder(Mx, My, Msum, Mcout, XO.YO, 1) , [Mcb^u:] ) , 

assert (half .adder (Mx , My , Msum .Mcout ,XO,YO, 1) ) , 

fail . 

half .adder . 


The  component  list  from  earlier  in  the  .‘^'’ction  will  be  used.  For  clarity,  the  same  netlist  is  shown 
below. 


nand.gate(na,nb,ncbar ,1,1,1). 
xor.gate(na,nb,n3um, 10,1,1). 
inv(ncbar .ncarry ,1,10. 1 ) 
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If  the  extraction  is  performed  in  the  order,  and_gate/0,  half^dder_cc/0,  and  ha]f_adder/0, 
the  result  will  be  the  following. 

xor_gate(na,nb.nsum, 10, 1,1). 
and_gate(na,nb,ncarry ,1 , 1,1). 

The  three  methods  presented  earlier  are  also  useful  in  solving  this  problem. 

There  is  one  type  of  extraction  problem  that  requires  greater  consideration.  Assume  we  define 
a  four-input  AND  gate  as  shown  in  Figure  21(a).  Using  the  new  extraction  rule  for  a  four-input 
AND  gate,  we  will  extract  the  circuit  shown  in  Figure  21(b).  Once  the  extraction  process  has 
completed,  two  different  interpretations  may  result.  In  one  case,  the  extraction  process  might  yield 
two  four-input  AND  gates  and  one  two-input  AND  gate.  In  the  second  case,  the  extraction  process 
might  yield  one  four-input  AND  gate  and  four  two-input  AND  gates.  Currently,  the  method 
for  solving  this  problem  is  to  exclude  VHDL  descriptions  for  models  that  contain  homogeneous 
structure. 


g)o 

_ (a) 

Figure  21.  Four-Input  AND  Gate  and  Simple  Circuit. 

The  limitations  discussed  in  this  chapter  effect  only  the  completeness  of  logic  extraction. 
Because  of  these  limitations,  it  is  possible  to  have  a  structural  specification  that  is  equivalent  to  its 
layout  specification,  but  not  have  the  relation  shown  true  by  logic  extraction.  These  limitations, 
however,  do  not  effect  the  correctness  of  logic  extraction. 
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IX.  Conclusions  and  Recommendations 


Conclusions 

The  objective  of  this  research  is  to  establish  a  formal  definition  of  logic  extraction,  discuss 
properties  of  logic  extraction  as  it  relates  to  formal  hardware-verification,  and  demonstrate  that 
logic  extraction  is  practical  for  VHSlC-class  designs.  We  have  established  a  definition  of  logic 
extraction  in  Prolog.  In  this  manner,  the  syntax  and  semantics  of  logic  extraction  are  established  in 
a  formal-executable  frame- work.  Further,  properties  of  VHDL  were  identified  and  defined  through 
a  formal-executable  frame- work.  As  such,  properties  of  soundness  and  guaranteed  termination  were 
proven.  Finally,  pragmatic  considerations  for  efficiency  are  met  by  taking  advantage  of  the  indexing 
trait  of  Quintus  Prolog. 

The  practical  aspects  of  logic  extraction  were  demonstrated  through  the  production  of  a 
working  integrated  circuit.  Further,  a  methodology  for  employing  logic  extraction  in  the  process 
of  formally  verifying  the  equivalence  relation  between  a  structural  VHDL  description  and  a  layout 
description  was  exhibited.  In  addition  to  guaranteeing  the  equivalence  between  a  structural  VHDL 
description  and  a  layout  description,  the  required  time  to  lay  out  a  custom  VLSI  chip  was  reduced 
due  to  the  diagnostic  side-effect  available  through  logic  extraction. 

This  work  hats  demonstrated  that  logic  extraction  is  not  as  simple  as  previously  thought. 
Logic  extraction  embodies  implicit  as  well  as  explicit  interconnection  properties.  Logic  extraction 
may  also  limit  the  design  problem  space  so  that  other  diagnostic  tools  may  be  used  to  examine 
portions  of  a  circuit  to  generate  further  information  for  the  designer.  Extracting  pin-to-pin  critical 
paths  is  but  just  one  example. 

Logic  extraction  is  not  just  limited  to  custom  VLSI.  Logic  extraction  may  be  used  to  assist 
verification  of  the  correctness  of  synthesis.  One  attribute  of  logic  extraction  is  the  ability  to  extract 
a  circuit  without  the  benefit  of  a  structural  VHDL  description.  This  attribute  may  further  aid  in 
the  future  respecification  of  nonreprocurable  digital  parts. 
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Recommendations  for  Future  Work 

The  research  explored  in  this  dissertation  provides  a  basis  for  several  new  areas  of  research. 
Within  this  section,  new  areas  of  possible  research  are  recommended. 

Deriving  logic  extraction  rules  from  an  increased  syntax  of  VHDL  would  be  highly  desirable. 
Structural  VHDL  was  shown  to  supply  sufficient  basis  for  constructing  logic  extraction  rules;  how¬ 
ever,  the  properties  being  proven  by  logic  extraction  also  exist  implicitly  in  data-flow  VHDL.  A 
tool  for  translating  structural  VHDL  to  data-flow  VHDL  is  presented  as  an  appendix  and  could  be 
reviewed  as  a  formal  method  for  bridging  the  gap  between  structural  VHDL  and  data-flow  VHDL 
for  logic  extraction. 

Now  that  critical  path  analysis  has  been  demonstrated  to  be  feasible  within  the  framework 
of  logic  extraction,  other  forms  of  analysis  similar  to  critical  path  analysis  appear  plausible.  There 
appears  to  be  potential  for  cell-by-cell  power  anedysis  of  VLSI  circuits.  Computations  based  on 
worst-case  analysis  or  a  typical-case  model  of  power  consumption  seem  feasible.  It  is  possible 
that  some  statistical  methods  may  be  used  to  predict  power  requirements  closer  to  actual  power 
requirements  through  extraction  rather  than  a  worst-case  power  requirements  analysis. 

Other  forms  of  path  analysis  may  be  considered.  Reliability  analysis  might  be  implemented 
through  extraction,  similar  to  critical-path  analysis.  Searching  for  the  most  unreliable  path  through 
a  system  appears  feasible  using  a  deviation  of  the  Huffman  model  for  critical-path  analysis. 

An  extension  to  the  logic  extraction  system  might  include  a  function  extraction  routine  for 
domino  (Weste  85:168)  transistor  networks.  Logic  extraction  rules  that  are  difficult  to  tailor  to 
some  transistor  networks  could  be  enhanced  through  a  new  type  of  logic  extraction  rule. 

GES  is  scheduled  for  use  on  a  million-transistor  project.  Portions  of  a  multi-chip  module  will 
probably  be  synthesized.  GES  will  be  used  to  extract  manually-generated  portions  of  the  design,  i.e., 
the  BIST  portions  (Seraf  91a)  (Seraf  91b)  of  the  design.  In  this  manner,  the  manually-generated 
portions  of  the  design  can  be  verified  and  the  synthesized  portions  extracted  to  a  gate-level  view 
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for  simulation  in  VHDL.  This  project  should  provide  a  basis  for  studying  the  utility  of  combining 
logic  extraction  with  synthesis  in  creating  large  integrated  circuits.  A  methodology  for  such  use 
may  be  generated  from  the  experience  gathered  here. 
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Appendix  A.  Definitions 


Definition  of  Behavioral  and  Structural  Specification 

In  this  section,  a  definition  will  be  given  for  behavioral  specification  and  structural  definition. 
For  the  purposes  of  the  presentation,  combinational  logic  will  be  used.  Afterwards,  an  example  of 
each  in  VHDL  will  be  offered  to  help  distinguish  the  two  from  each  other. 

A  behavioral  specification  is  an  algorithmic  description  of  how  a  specified  system  or  compo¬ 
nent  is  expected  to  react  to  a  given  set  of  input  stimuli.  There  is  usually  nothing  or  very  little 
provided  in  the  behavioral  specification  as  to  the  internal  physical  makeup  and  interconnections 
of  the  specified  system  of  component.  The  behavioral  specification  may  be  represented  abstractly 
as  in  Figure  22.  The  boundary  of  the  specified  system  or  component  is  well  defined.  By  well 
defined  we  mean  that  all  inputs  and  outputs  are  identified  at  the  boundary  of  the  specified  device 
or  component. 


Figure  22.  Abstract  View  of  a  Behavioral  Specification. 

From  Figure  22,  the  inputs  to  the  specified  device  or  componerii,  are  represented  as  I  where 
/  =  lo, ...,  »m  and  0  <  m.  The  outputs  from  the  specified  device  nr  component  are  represented  as  O 
where  O  =  oq,  ...,  o„  and  0  <  n.  The  algorithm  for  the  specified  device  or  component  is  represented 
by  the  relation  R  where  R  C  /  x  O. 


86 


A  structural  specification  for  a  specified  device  or  component  provides  a  description  of  the 
internal  physicad  maJceup  and  interconnections.  The  following  criteria  are  used  to  determine  a 
structural  specification. 

1.  A  structural  specification  is  not  a  behavioral  specification. 

2.  A  structuraJ  specification  may  be  constructed  from  one  or  more  interconnected  behavioral 
specifications. 

3.  A  structural  specification  may  be  constructed  from  one  or  more  interconnected  structural 
specifications. 

4.  A  structural  specification  may  be  constructed  from  one  or  more  interconnected  behavioral 
specifications  and  structural  specifications. 

The  behavioral  specification  may  be  viewed  as  a  procedural  method  for  portraying  a  specified  device 
or  component.  Alternatively,  the  structural  specification  may  be  viewed  as  a  declarative  method 
for  portraying  a  specified  device  or  component. 

The  following  is  a  VHDL  model  of  a  behavioral  specification. 
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entity  adder  is 

port(i0,il,i2:  in  bit; 

oO.ol  :  out  bit); 
end  adder; 

architecture  behave  of  adder  is 

function  bv  (input  :  bit)  return  integer  is 
begin 

If  (input  =  ’!’)  then  retum(l); 

else  return ( 0) ;  end  if; 

end; 

function  bv_inv  (input  :  integer)  return  bit  is 
begin 

If (input  =  0)  then  return(’O'); 
else  return(’l’):  end  if; 
end; 

begin 

process 

begin 

uait  on  i0,il,i2; 

if  ((bv(i0)+bv(il)+bv(i2))  <  2)  then 
oO  <=  bv_inv(bv(i0)+bv(il)+bv(i2)) ; 

else 

oO  <=  bv_inv(bv(i0)+bv(il)+bv(i2)-2) ; 
end  if; 

if  ((bv(i0)+bv(il)+bv(i2) )  <  2)  then 
ol  <=  bv_inv(0); 

else 

ol  <=  bv_inv(l); 
end  if; 
end  process; 
end  behave; 


From  the  VHDL  description  the  inputs  and  output  are  enumerated  as  iO,  il,  i2  for  the  inputs  and 
o0,ol  for  the  outputs.  The  assigned  values  for  the  outputs  are  determined  algorithmically  from  the 
inputs.  There  is  nothing  in  the  VHDL  description  that  indicates  the  physical  construction  of  the 
specified  device  or  component. 

The  following  VHDL  description  is  a  structural  specification  of  the  same  device. 
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entity  adder  is 

port(i0,il,i2;  in  bit; 
oO.ol  ;  out  bit); 

end  adder; 

architecture  structure  ot  adder  is 

signal  p,q>r  :  bit; 

component  half_add 
port  (a,b  :  in  bit; 

s.cbar  :  out  bit); 
end  component; 

begin 

ol  <=  q  nand  r; 

hal  :  hall.add  port  map 
(  a  =>  iO, 
b  =>  il, 
s  =>  p, 
cbeir  =>  q) ; 

ha2  ;  half.add  port  map 
(  a  =>  p, 
b  =>  i2, 
s  =>  oO, 
cbar  =>  r) ; 

end  structure; 


Definitions  for  Other  Terms 

Hardware  description  language  (HDL)  “a  language  used  to  describe  a  circuit’s  behavior  or 
structure.”  (deGeu  89:27) 

Logic  synthesis  “creation  of  a  gate- level  netlist  from  a  register-transfer  level  description.”  (deGeu 
89:27) 

Many-valued  Logic  an  algebraic  system  consisting  of  more  than  two  truth  values  (Resch  69:17). 

Mapping  “the  process  of  formulating  a  design  in  terms  of  the  cells  available  in  a  given  parts 
library.”  (deGeu  89:27) 
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Netlist  “a  circuit  design  description  in  terms  of  structural  elements  and  their  interconnections. 


(deGeu  89:27) 
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Appendix  B.  Efficiency  Issues 


Foremost  in  the  design  of  GES  was  the  concern  for  correct  execution  of  extraction.  For  designs 
containing  a  large  number  of  components,  efficiency  of  the  system  does  become  a  practical  concern. 
In  a  sense,  this  appendix  addresses  the  pragmatics  of  performing  extraction. 

Logic  Extraction 

The  extraction  process  can  occupy  a  large  amount  of  CPU  time.  In  order  to  help  reduce 
the  CPU  time  involved  in  extracting  components,  some  heuristics  are  offered.  The  first  heuristic 
identifies  low-level  signature  components  of  higher  level  components.  The  second  heuristic  elimi¬ 
nates  duplicate  transistors  where  possible.  The  third  heuristic  seeks  to  reduce  the  complexity  of 
extraction-rules.  These  three  heuristics  are  explained  below.  Finally,  the  knowledge  of  term  in¬ 
dexing  in  Quintus  Prolog  is  used  to  increase  the  execution  speed  of  logic  extraction  with  minimal 
impact  on  memory. 

Extraction  Without  Indexing 

The  complexity  of  logic  extraction  consists  of  two  parts.  These  parts  concern  the  number  of 
components  to  be  examined  and  the  number  of  extraction  rules  used.  For  the  purpose  of  discussion 
we  will  assume  a  component  data  base  consisting  of  one  single  type  of  component.  By  a  single 
type  of  component,  we  mean  that  the  functor/arity  of  all  components  is  the  same.  Assume  that 
the  component  data  base  is  of  size  n.  Additionally,  assume  a  logic  extraction  rule  matching  m 
components  of  the  same  functor/arity  of  the  component  data  base.  Assume  also  the  process  of 
logic  extraction  as  described  in  Prolog  for  nonindexed  terms  in  the  component  data  base.  Under 
such  conditions,  we  can  show  the  complexity  is  of  0(n'”). 
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Through  induction,  the  following  assertion  will  be  proven 


{{E  1)  A  (Vm.(J?  (m  —  1))  =>  {E  m)))  =>  'im.{E  m) 

where  E  represents  the  case  of  an  extraction  rule  matching  m  components.  Considering  the  base 
case,  an  extraction  rule  must  contain  at  least  one  matching  component.  The  extraction  rule  will 
execute  n  times  for  n  components  in  the  data  base  since  the  backtracking  mechanism  of  Prolog 
requires  it.  Therefore,  for  (m  =  1)  we  have  0(n). 

Assume  now  the  complexity  of  for  the  case  of  matching  (m  —  1)  components. 

Under  this  assumption,  it  is  necessary  to  examine  the  cause  for  an  extraction  rule  to  exhibit  this 
behavior.  We  ’'■'•11  use  the  following  template  for  an  extraction  rule. 

E 

Ci(TiST2‘,...,7V), 

C2{TlTl...,T^), 

not.connected{Signala ,  Signale), 

retract(C,iT,\Tl...X)), 

retract{C2{TlTl...X))^ 

re<rad(C(„_i)(T<'”-*\ . . . ,  7^'"-*^)), 

asserta{E{Signalf)), 

fail. 

E. 

In  order  to  force  backtracking  complexity  of  each  C,,  1  <  »  <  (m  —  1),  would  have  to 

succeed  followed  by  the  failure  of  notjconnected/2. 

Finally,  the  rn*'*  matching  rule  is  added  after  By  the 

backtracking  nature  of  Prolog,  for  every  possible  combination  of  the  first  (m  —  1)  matching  rules, 
the  m*'*  matching  rule  will  be  tried  n  times.  By  assumption,  the  first  (m  —  1)  matching  rules  are 
executed  times.  By  multiplication  we  have  x  n  =  n'"  rendering  a  complexity  of 

Oln”*). 
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Signature  Components 


Clauses  within  Prolog  rules  are  executed  sequentially.  Thus,  the  order  in  which  clauses  appear 
in  Prolog  rules  can  affect  execution  efficiency*.  This  procedural  aspect  of  Prolog  will  be  investigated 
below  to  help  understand  how  it  can  be  used  to  speed  up  extraction.  Assume  we  are  interested  in 
increasing  the  execution  efficiency  of  a  particular  Prolog  rule,  called  compi  shown  below. 

comp  I 

subcompA{Ai ,  A2, . . . ,  A<,), 
subcompB(Bi ,  B2, . .  ■ ,  Bp), 
subcompC{Ci ,  C2, . . . ,  Cq), 
retracl{subcompA{A\,  A2, . . . ,  Aj,)), 
retract(subcompB{Bi ,  S2,  •  ■  ■  >  Bp)), 
retract{subcompC{Ci,C2,  ■  ■ .,  Cq)), 
asserta(compi {Coi,Co2, . .  .,Cor)), 
fail, 
compi . 

Assume  that  there  are  j  subcompA  components,  k  subcompB  components,  and  i  subcompC 
components.  Should  execution  of  the  compi  rule  lead  to  m  compi  components  exhausting  all  j,k, 
and  /  subcomponents,  respectively,  then  j  =  k  =  I  =  m.  Assume,  now,  the  existence  of  another 
component,  comp2,  with  the  rule 

comp2 

subcompB{Bi ,  B2,  ■  ■  ■,  Bp), 
subcompC {C\,C2,  ■  ■  ■ ,  Cq), 
retract{subcompB{Bi ,  B2.  •  •  •  >  Bp)), 
retract{subcompC{Ci,C2,  ■  ■ 
asserta(comp2{Coi,Co2, . . . ,  Co,)), 
fail. 
comp2 . 

Assume,  too,  that  n  comp2  components  exist  and  that  after  the  application  of  both  rules, 
compx  and  comp2,  all  j,k,  and  /  subcomponents  will  be  exhausted.  From  the  above  extraction 
process,  then,  j  =  m  and  k  —  I  =  m  +  n.  Since  subcompA  occurs  only  in  compi,  subcompA  is 
called  the  signature  of  comp\. 


'For  those  more  familiar  with  Prolog,  the  terms  shallow  and  deep  backtracking  may  come  to  mind.  For  those 
wishing  to  know  more  about  these  terms,  a  discussion  is  found  in  (Sterl  1986) 
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Furthermore,  extraction  using  the  Prolog  rule  compi  before  the  Prolog  rule  comp2  is  preferred. 
If  we  were  to  use  the  Prolog  rule  comp2  first,  then  all  k  subcompB  components  would  be  searched  for 
inclusion  in  comp2-  Whereas,  using  the  Prolog  rule  compi  first  would  reduce  the  search  space  to  k  — 
m  subcompB  components  for  comp2 .  The  search  rationale  is  further  predicated  on  the  assumption 
that  some  of  the  parameters  for  a  subcomponent  aid  in  the  selection  of  subsequent  subcomponents  in 
a  Prolog  rule.  To  help  understand  how  parameters  aid  in  the  selection  of  subsequent  subcomponents 
consider  the  following  explanation. 

Assume  that  some  parameter  of  subcompA,  called  where  1  <  /i  <  o,  is  connected  to  some 
parameter  of  subcompB,  called  B,  where  1  <  »  <  p,  in  compi.  In  the  execution  of  the  Prolog 
rule  compi,  Prolog  will  attempt  to  find  a  component  in  the  component  database  called  subcompA 
before  looking  for  subcompB.  Once  a  component  is  found  satisfying  subcompA,  the  parameters  of 
subcompA  will  be  instantiated  (or  unified)  to  the  values  corresponding  to  the  component  in  the 
component  database.  Since  B,  =  Ah  in  subcompB,  Bi  is  instantiated  to  the  value  of  Ah  and  will 
therefore  constrain  Prolog  to  finding  a  component  that  satisfies  subcompB  and  Bi.  The  additional 
constraint  of  B,  reduces  the  possible  components  to  be  considered  in  satisfying  compi. 

Consider  the  following  example  using  the  Prolog  rule  described  earlier  for  a  D  flip-flop; 

dfl 

clk_inv(P2.Pl.G,X,Xloc.Yloc,l), 
tgate(Pl ,P2,D,X,_,_), 
inv(X,G, , 
reniove_tgate(Pl,P2,D,X) , 
retract(clk_inv(P2,Pl ,G,X,Xloc,yioc, 1) ) , 
retract ( inv(X, G, 1) ) , 
assertaCdf f (PI ,P2 ,D ,G ,Xloc , Yloc , 1) ) , 
fail . 
dff . 

We  may  compare  the  dff  rule  to  a  new  rule  concerning  xor. 
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xor 

tgate(B,Bnot,A,XOR,_,_) , 
inv(B,Bnot,_,_,l) , 
inv(A,Anot, , 
tgat  e ( Bnot , B , Anot , XOR .Xloc.Yloc), 
retract(inv(B,Biiot,_,_,l)) , 
retract(inv(A, Anot, , 
remove_tgate(Bnot,B, Anot. XOR) , 
remove_tgate(B,Bnot,A,XOR) , 
as  s  erta( xor ( A , Anot , B , Bnot , XOR , Xloc , Yloc , 3) ) , 
fail, 
xor. 


Both  dff  and  xor  share  transmission  gates  and  inverters;  however,  clk_inv  only  occurs  in  dii. 
In  this  case,  clk_inv  would  be  considered  a  signature  component  for  dff.  Also  notice  in  xor  that 
finding  tgate(B,Bnot,A,XOR,_,_)  would  easily  lead  to  location  of  one  inverter,  aid  in  the  quick 
selection  of  a  second,  and  to  location  of  the  second  transmission  gate. 


Eliminating  Duplicates 


The  second  heuristic  seeks  to  eliminate  duplicate  transistors.  Since  only  digital  logic  is  of 
interest,  additional  transistors  (added  to  increase  the  drive  capacity  of  a  circuit)  needlessly  increase 
the  search  space.  When  only  looking  for  the  logic  functionality  of  a  circuit,  no  additional  information 
is  gained  from  such  transistors.  The  following  is  a  Prolog  rule  adopted  to  eliminate  duplicate 
transistors  while  reading  in  the  transistor  netlist  from  a  mask  layout  description. 

remove_dup_trans 
read(X) , 

remove_dup_trans(X) , ! , 
remove_dup_trans . 
remove_dup_tr2uis . 

remove_dup_tr2uis(«nd_of_file)  !. 
r einove_dup_trans (p(A,B,C, 
ptraiis(A,B,C,_,_), ! . 
remove_dup_trans(n(A,B,C, 
ntran8(A,B,C,_,_) , ! . 
remove_dup_tran8(p(A,B,C,W,L,X,Y)) 
asserta(p(A,B,C,W,L,X,Y}}, ! . 
r emove_dup_tran8 (n(A,B,C,W,L,X,Y))  •- 
as8erta(n(A,B,C,W,L,X,Y)), ! . 
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Reducing  Prolog  Rule  Complexity 


The  third  heuristic  addresses  rule  complexity.  Rule  complexity  is  directly  related  to  the 
number  of  components  that  must  be  matched.  Therefore,  rule  complexity  increases  as  the  number  of 
components  that  must  be  matched  increases.  In  general,  simpler  rules  increase  execution  efficiency. 


An  example  of  how  rule  complexity  influences  efficiency  may  be  found  in  the  identification  of 
registers  from  a  component  netlist.  Assume  the  following  rule,  registerl,  for  registers. 

registerl 

clk_iiiv(R,P.Cl.Clbar,X,Y), 

inv(P,R,_,_) , 

tgate(In,P,Clbar,Cl,_,_), 

tgate(R,Q,C2bar,C2,_,_) , 

clk_inv(S,Q,C2,C2b2u:,_,_) , 

inv(q,S,_,_), 

tgate(S,Out,Abar , 

retract ( clk_ inv ( R , P , C 1 , C Ibaor , X , Y) ) , 

retract(inv(P,R,_,_)) , 

retract (tgate (In, P.Clbar, Cl, , 

r etract (tgate (R , Q , C2bar , C2 , 

retract (clk_inv(S,Q,C2,C2bar, 

retract(inv(q,S, 

retract(tgate(S,Out,Abar,A,_,_)) , 

asserta(register (In ,Oat , Cl , Clbar , C2 , C2bar , A , Abar , X , Y) ) , 
fail. 

registerl . 


Figure  23  is  a  diagram  of  the  component  extracted  by  the  registerl  rule. 


I 

Abar 

— tki — 

Cl 

Cl 

Clbai 

C2 

A 

Figure  23.  Schematic  for  registerl  Extraction  Rule. 
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Assume  a  component  netlist  consisting  of  c/iJnti,  inv,  and  igaie  that  when  extracted  form 
j  registers  with  no  residual  components.  Assume  also  that  a  register  is  constructed  from  two  D 
flip-flops,  described  below,  and  a  transmission  gate  as  in  Figure  24  and  by  the  Prolog  rule  for 
register2  that  follows. 


register2 

dll(In.R,Cl.Clbar.X,Y), 
dYf(R,S.C2,C2bar._,_). 
tgata (S, Out, Abar, , 
retract (dll (In, R, Cl, Clbar, X, Y) ) , 
retract(dll(R,S,C2,C2bar,_,_)) , 
retract (tgate (S, Out, Abar, A, , 

asserta(register(In,0at,Cl,Clbar,C2,C2bar ,A,AbaLr ,X,Y)) , 
lail. 

register2. 

dll 

clk_inv(R,P,Cl , Clbar, X,Y) , 
inv(P,R,_,_) , 
tgate(In,P,Clbar,Cl,_,_) , 
retract(clk_inv(R,P,Cl,Clbaur,X,Y)) , 
retract(inv(P,R,_,_)) , 
retract (tgate(In,P, Clbar, Cl, , 
asserta(dll(In,R, Cl, Clbar, X,Y)) , 
lail. 
dll. 


Figure  24.  Schematic  for  register2  Extraction  Rule. 


Using  the  rules  register2  and  there  are  k  dff,  where  k  =  2*  j,  and  j  tgate.  If  the  rule  register! 
is  considered,  there  are  k  clk-inv,  k  inv,  and  /  igaie  where  I  =  j  +  k. 


97 


For  the  purpose  of  the  illustration  consider  registerl,  dff,  and  registerSin  the  following  manner. 
The  parts  of  each  rule  that  query  the  fact  database  will  also  be  numbered  to  aid  in  the  discussion, 
registerl 

Rll  clk_inv(R,P.Cl.Clbar,X,Y), 

R12  inv(P,R,_._) , 

R13  tgate(In,P,Clbar,Cl,_,_) , 

R14  tgate(R.Q,C2bar,C2,_._). 

R15  clk_inv(S,q,C2,C2bar,_,_) , 

R16  inv(Q,S,_,_), 

R17  tgate(S,Out.Abar,A,_,_) , 

dff 

D1  clk_inv(R,P.Cl.Clbar,X,Y), 

D2  inv(P,R,_._) , 

D3  tgate(In,P,Clbar,Cl,_,_) , 

regiater2 

R21  dff(In.R.Cl,Clbar,X,Y). 

R22  dff (R,S,C2,C2bar,_._). 

R23  tgate(S,Out,Abar,A,_,_) , 


Statements  Rll,  Dl,  and  R21  may  be  considered  as  enumeration  statements  (or  ENUMERATE) 
since  they  simply  pick  off  from  the  database  of  facts  the  next  available  fact  until  all  facts  that 
satisfy  predicate/arity  have  been  exhausted.  Statements  R12...R17,  D2,  D3,  R22,  and  R23,  may  be 
considered  as  database  queries  (or  QUERY)  since  some  or  all  of  their  parameters  have  been  unified 
based  upon  the  previous  statements.  If  we  also  assume  the  worst-case  ordering  of  components  such 
that  the  first  k  clk.inv  actually  form  the  second  dff,  the  rule  registerl  will  “fail”  k  times  before  it 
will  actually  begin  identifying  registers.  Furthermore,  the  k  times  that  registerl  failed  it  identified 
k  dff.  Using  registerl  to  identify  registers,  there  will  be  at  most  k  failed  ENUMERATES  and  4  ♦  it 
failed  QUERYs.  The  failed  QUERYs  are  incurred  since  R12,  R13,  and  R14  succeed,  but  R15  will 
fail  causing  the  entire  sequence  to  backtrack  and  try  a  new  clk-inv. 

Consider  the  rules  rfj^and  register2  on  the  same  component  netlist.  The  rule  dff  will  succeed 
until  all  clk-inv  have  been  exhausted.  If  we  assume  that  the  dff  components  were  ordered  in  the 
worst  case  then  register2  will  have  only  k  failed  ENUMERATES  and  no  more.  The  A*  k  failed 
QUERYs  from  registerl  were  avoided  by  reducing  its  complexity. 
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Generally,  the  above  three  heuristics  have  been  found  to  increase  the  speed  of  execution. 
Identifying  signature  components  may  be  dependent  on  the  composition  of  a  given  component 
netlist  and  should  therefore  be  considered.  Eliminating  duplicate  components  not  only  reduces 
the  search  space  but  allows  for  parallelization  of  the  extraction  process.  Finally,  reducing  rule 
complexity  increases  efficiency  by  reducing  search  failures. 
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Appendix  C.  Using  HOL 


Preliminaries 

Theorems  may  be  proven  in  IIOL  either  interactively  or  through  the  ML  “let”  conunand. 
Interactive  theorem  proving  is  performed  by  entering  line-by-line  commands  in  order  to  manipulate 
an  HOL  goal  stack  and  HOL  assumption  stack.  Entering  theorems  in  HOL  through  the  ML  “let” 
command  inserts  a  proven  theorem  into  a  theory  data  file.  Before  HOL  statements  are  presented, 
some  symbol  definitions  will  be  provided  from  the  HOL  manual. 


Infix  operators  (Gordo87;3) 


tl=t2" 

is 

equivalent  to 

"=  tl  t2*' 

(read  as 

"tl 

equals  t2") 

is 

equivalent  to 

tl  t2” 

(read  as 

"the  pair  (tl,t2)") 

tl/\t2" 

is 

equivalent  to 

•'/\  tl  t2" 

(read  as 

"tl 

and  t2") 

tl\/t2" 

is 

equivalent  to 

"\/  tl  t2“ 

(read  as 

"tl 

or  t2") 

tl==>t2" 

is 

equivalent  to 

'•==>  tl  t2'' 

(read  as 

"tl 

inplies  t2") 

tl<=>t2" 

is 

equivalent  to 

"<=>  tl  t2'' 

(read  as 

"tl 

iff  t2") 

Binders  (Gordo87:3) 


" !x.t" 

is 

equivalent 

to 

"!(\x.t)" 

(read  as 

"for  all  X,  t") 

"?x.t" 

is 

equivalent 

to 

"?(\x.t)" 

(read  as 

"for  some  x,  t") 

"Cx.t" 

is 

equivalent 

to 

"«(\x.t)" 

(read  as 

"an  X  such  that  t") 

Notice  that  several  symbols  are  represented  through  combinations  of  characters.  The  A  is 
represented  in  HOL  by  /\  for  logical  conjunction.  The  V  is  represented  in  HOL  by  \/  for  logical 
disjunction.  The  =>•  is  represented  in  HOL  by  ==>  for  logical  implication.  The  is  represented 
in  HOL  by  <=>  for  equivalence.  The  V  is  represented  in  HOL  by  !  for  universal  quantification. 
The  3  is  represented  in  HOL  by  ?  for  existential  quantification.  Finally,  the  A  is  represented  in 
HOL  by  \  for  lambda  notation.  HOL  prompts  the  user  for  input  through  the  use  of  a  #  prompt. 
The  ; ;  is  used  to  terminate  an  HOL  command. 
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Showing  Structvure  Implies  Behavior  Through  HOL 


The  device  in  Figure  25  is  a  three-input  component  with  a  single  output.  The  figure  illus¬ 


trates  several  methods  for  specifying  the  behavior  of  the  same  device.  The  behavior2il  specification 


representations  shown  are  VHDL,  HOL,  a  Karnaugh  Map,  emd  a  Truth  Table.  The  translation  of 


VHDL  into  HOL  is  considered  part  of  this  research. 


ii 


(x=’l*)  and  (y=*r^ 
and  (2= ’O’)  then 
out  <=  ’ 1 ’ ; 
end  if; 

(x=’l’)  and  (y=’l’) 
and  (z=’l’)  then 


out  <=  ’O’; 
end  if; 

(x=’0’)  and  (y=’0’) 
and  (z=’0’)  then 
out  <=  ’0’ ; 
end  if ;  . 


VHDL 


"I 


□□□a 


Karnaugh  Map 


X  T  2 

out  \ 

0  0  0 

0 

0  0  1 

d 

0  10 

d 

0  1  1 

d 

10  0 

d 

1  0  1 

d 

1  1  0 

1 

^1 1 1 

oy 

Truth  Table 


Figure  25.  Behavioral  Specifications  for  a  Three-Input  Device. 


Three  structural  specification  representations  are  illustrated  in  Figure  26.  For  each  structural 


specification,  the  gate  description,  VHDL  description,  and  HOL  description  are  shown.  However, 


nothing  is  known  about  the  relation  between  the  structural  specifications  shown  in  Figure  26  and 


the  behavioral  specification  shown  in  Figure  25. 
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Figure  26.  Three  Implementation  Specifications. 
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Before  a  comparison  can  be  made  between  the  behavioral  specification  and  the  structural 
specifications,  a  common  specification  language  must  be  chosen.  For  the  purpose  of  this  research, 
the  basis  language  will  be  VHDL.  However,  the  VHDL  descriptions  must  be  transformed  to  another 
specification  language  to  perform  formal  hardware- verification.  Since  HOL  is  to  be  used  as  the  proof 
mechanism,  the  VHDL  descriptions  must  be  translated  to  HOL. 

From  Figures  25  and  26  the  following  HOL  definitions  were  written  for  the  behavioral  spec¬ 
ification  and  the  three  implementation  specifications. 

let  behave.spec  = 

nes.def initionC 'behave.spec' . 

"!x  y  2  out.  behave.spec  x  y  z  oat  = 

(((x  =  T)  A  (y  =  T)  A  (z  =  F)  ==>  (out  =  T))  A 

((x  =  T)  A  (y  =  T)  A  (z  =  T)  ==>  (out  =  F))  A 

((x  =  F)  A  (y  =  F)  A  (z  =  F)  ==>  (out  =  F)))"):; 


let  ifflpll.spec  = 

neu. def inition( ' impll.spec ' , 

"!x  y  z  out.  iapll.epec  x  y  z  out  = 

(out  =  X  A  y  A  "z)") ; ; 

let  iBpl2_spec  = 

nev_delinition( 'inpl2.spec' , 

"!x  (y:bool)  z  out.  impl2_spec  x  y  z  out  = 
(out  =  X  A  *z)"):: 

let  implS.spec  = 

nev. def inition( ' inplS.spec' , 

"!y  z  out.  impl3_spec  y  z  out  = 

(out  =  y  /\  "z)");; 


The  HOL  definition  is  the  method  for  writing  behavioral  specifications  and  structural  specifications. 
In  order  to  establish  that  the  structural  specifications  will  perform  as  described  by  the  behavioral 
specification,  a  proof  will  be  constructed  in  HOL.  For  each  structural  specification,  a  theorem 
will  be  generated  stating  that  for  all  inputs  and  outputs,  the  structural  specification  implies  the 
behavioral  specification.  The  first  theorem, 


'i  X  y  z  out.  impllspec  x  y  z  out  ^  behavespec  x  y  z  out, 


(13) 
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is  shown  in  HOL  below.  Everything  contained  within  quotes  is  considered  to  be  the  theorem. 


#8et_goal([] ."!x  y  z  out. 

inpll.spac  x  y  z  out  ==>  b«have_spac  x  y  z  out");; 

"!x  y  z  out.  impll.spec  x  y  z  out  ==>  bahava_spec  x  y  z  out" 

()  :  void 

« 


The  next  step  in  the  proof  process  is  to  remove  the  universal  quantifier  through  a  process  in 
HOL  called  generalization.  The  procedure  for  manipulating  the  theorem  to  be  proved  in  HOL  is 
performed  through  a  utility  called  expand.  The  expand  utility  provides  a  buffer  between  the  user 
and  the  theorem  to  be  proved.  This  prevents  the  user  from  performing  an  incorrect  manipulation 
of  the  proof.  In  HOL,  procedures  called  tactics  are  passed  through  expand  to  tell  HOL  how  the 
theorem  is  to  be  modified.  In  order  to  generalize  the  universally  quantified  variables,  the  GEI_TAC 
tactic  is  used.  Since  GEI.TAC  only  generalizes  one  variable  at  a  time,  a  modifier  called  REPEAT  is 
used  to  perform  GEI_TAC  until  it  fails. 

«expand(REPEAT  GEI.TAC) ; ; 

OK. . 

"impll_8pec  X  y  z  out  ==>  behave.spec  x  y  z  out" 

()  :  void 

« 


The  next  step  is  to  replace  uipll.spec  and  bahave.spec  with  their  definitions.  This  process 
is  performed  using  the  REWRITE_TAC  []  tactic. 

#axpand(REVRITE_TACCiiiipll_8pec;behave_spec]  } ; ; 

OK.  . 

"(out  =  X  A  y  /\  ~z)  ==> 

(x  /\  y  A  *z  ==>  out)  A 
(x  A  y  A  z  ==>  *out)  A 
('X  /\  ’y  A  "z  ==>  'out)" 

()  :  void 

* 
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At  this  point,  the  antecedent  of  the  implication  is  assumed  true  through  a  tactic  called 
STRIP_TAC.  This  process  will  create  a  list  of  assumptions  or  append  to  a  list  of  assumptions  should 
a  list  exist.  Everything  that  appears  between  C  ]  is  considered  to  be  an  assumption. 

#expaiid(STRIP_TAC) ; ; 

OK.  . 

"(x  A  y  /\  'z  ==>  out)  /\ 

(x  /\  y  /\  z  ==>  "out)  A 
("x  /\  *y  /\  "z  ==>  "out)" 

[  "out  =  X  /\  y  /\  *z"  ] 

()  :  void 

« 


The  ASM_REWRITE_TACU  is  different  from  the  REWRITE.TACD  in  that  substitutions  will  be 
performed  within  the  theorem  based  upon  the  assumptions.  The  substitutions  are  performed  by 
matching  the  left-hand  side  of  the  assumption  with  some  element  within  the  theorem  and  rewriting 
that  element  within  the  theorem  with  the  right-hand  side  of  the  assumption. 

#«xpand(ASM_REWRITE_TACC] ) ; ; 

OK. . 

"(x  A  y  A  Z  ==>  -(x  A  y  A  *z))  A 
('x  /\  *y  A  'z  ==>  '(x  /\  y  /\  'z))" 

[  "out  =  X  /\  y  /\  *z"  ] 


()  :  void 

« 


The  ASM_REWRITE_TAC  []  and  REWRITE_TAC  □  tactics  also  perform  other  functions.  One  such  func¬ 
tion  is  to  recognize  tautologies  through  simple  pattern  matching.  In  this  case,  the 
ASM_REWRITE_TAC  □  tactic  eliminated  (x  /\  y  A  "z  ==>  x  /\  y  /\  "z)  after  the  substitution. 

The  next  step  is  to  break  up  the  theorem  into  two  simpler  theorems.  The  COIJ_TAC  is  used 
to  create  two  separate  theorems  from  a  larger  theorem  formed  by  the  conjunction  of  two  separate 
theorems. 
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«expaiid(COIJ_TAC) ; ; 

OK. . 

2  subgoals 

"*x  /\  *y  /\  *z  ==>  *(x  A  y  /\  'z)" 
[  "out  =  X  /\  y  /\  "z"  ] 

"X  /\  y  /\  z  ==>  '(x  /\  y  /\  *z)" 

[  "out  =  X  /\  y  /\  "z"  ] 

()  :  void 

» 


The  theorem  that  is  now  being  manipulated  is  the  bottom  one  in  the  previous  list.  Once 
again,  the  STRIP_TAC  tactic  is  used  to  assume  the  antecedent  of  the  implication  true. 

#expand(STRIP_TAC) ; ; 

OK.  . 

"'(x  A  y  A  -z)" 

C  "out  =  X  /\  y  /\  "z"  ] 

C  "X"  ] 

C  "y»  ] 

C  "z"  ] 


()  :  void 

« 


When  an  assumption  is  a  literal,  the  literal  is  assumed  true.  Therefore,  every  occurrence  of 
the  literal  in  the  theorem  will  be  replaced  with  a  “true”  value  when  using  the  ASM_REWRITE_TAC  □ 
tactic. 

#expand(ASM_REWRITE_TAC[] ) ; ; 

OK. . 

goal  proved 

...  1-  *(x  A  y  A  -z) 

I-  X  /\  y  /\  z  ==>  *(x  A  y  /\  "z) 

Previous  subproof : 

"'X  A  -y  A  *z  ==>  -(x  A  y  A  'z)" 

[  "out  =  X  /\  y  /\  "z"  ] 


0  :  void 

« 
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Once  a  theorem  has  been  shown  to  be  true,  HOL  responds  with  “goal  proved”  and  a  recapit¬ 
ulation  of  the  theorems  manipulated  up  to  the  point  of  proving  it  true.  Should  any  other  theorems 
remain  to  be  shown,  HOL  will  present  them  to  the  user.  The  “Previous  subproof;”  reply  tells  the 
user  which  theorem  is  to  be  proven  next.  As  before,  the  STRIP_TAC  is  employed  to  assume  the 
antecedent  true. 

#expand(STRIP_TAC) ; ; 

OK.  . 

"'(x  A  y  A  -z)" 

C  "out  =  X  /\  y  /\  'z"  ] 

C  "*x"  ] 

I  "*y"  ] 

C  "*z"  ] 

()  :  void 

# 


At  this  point,  an  ASM_REWRITE_TAC  []  tactic  will  complete  the  proof. 

#expand(ASM_REWRITE_TACC] ) ; : 

OK. . 

goal  proved 

...  I-  "(x  /\  y  /\  *z) 

I-  'X  /\  *y  /\  *z  ==>  '(x  /\  y  /\  *z) 

I-  (x  /\  y  /\  z  ==>  "(x  /\  y  /\  *z))  A 
('X  /\  "y  /\  "z  ==>  *(x  /\  y  /\  'z)) 

.  I-  (x  /\  y  /\  'z  ==>  out)  /\ 

(x  /\  y  /\  z  ==>  *out)  /\ 

('X  /\  "y  /\  'z  ==>  'out) 

I-  (out  =  X  /\  y  /\  'z)  ==> 

(x  /\  y  /\  'z  ==>  out)  /\ 

(x  /\  y  A  z  ==>  'out)  /\ 

('X  /\  'y  A  "z  ==>  'out) 

I-  impll.spec  x  y  z  out  ==>  behave.spec  x  y  z  out 

I-  !x  y  z  out.  impll.spec  x  y  z  out  ==>  behave.spec  x  y  z  out 

Previous  subproof : 
goal  proved 
()  :  void 
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Once  all  of  the  theorems  have  been  shown  to  be  true,  HOL  responds  by  showing  all  of  the  theorems 
that  were  generated,  to  include  the  first  theorem.  At  this  point,  it  has  been  shown  that 


'i  X  y  z  out.  impll^spec  x  y  z  out  =>  behave.spec  x  y  z  out. 


(14) 


Two  more  structural  specifications  remain  to  be  examined.  The  next  HOL  proof  will  demonstrate 
how  HOL  tactics  may  be  combined  to  shorten  the  proof  process. 

The  second  HOL  proof  will  show 


'i  X  y  z  out.  impl2.spec  x  y  z  out  =>  behave.spec  x  y  z  out. 


(15) 


#set_goal( [] ," !x  y  z  out. 

#  impl2_8pec  x  y  z  out  ==>  behav«_spec  x  y  z  out");; 

"!x  y  z  out.  impl2_spec  x  y  z  out  ==>  behave_spec  x  y  z  out" 

0  :  void 

« 


Experience  with  the  first  HOL  proof  would  suggest  that  two  HOL  tactics  could  be  used  on 

the  present  theorem.  The  REPEAT  GEH.TAC  and  REWRITE_TACn  tactics  may  be  invoked  through 

the  same  expand  HOL  command.  This  is  possible  by  the  use  of  THEI.  THEM  works  by  applying  the 

tactic  on  the  left-hand  side  to  the  theorem  first  followed  by  the  right-hand  side  tactic. 

#expand( REPEAT  GEI.TAC  THEI  REWRITE_TAC[impl2_spec;behave_8pec] ) ; ; 

OK.  . 

"(out  =  X  /\  'z)  ==> 

(x  /\  y  A  'z  ==>  out)  A 
(x  /\  y  /\  z  ==>  'out)  /\ 

('X  /\  'y  /\  *z  ==>  "out)" 

()  :  void 

« 


Continuing  to  Draw  upon  experience  from  the  previous  proof,  the  remainder  of  the  HOL 
proof  is  performed  below. 
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#expaiid(STRIP_TAC  THEM  ASM_REWRITE_TAC [] ) ; ; 
OK. . 

"(x  A  y  /\  "z  ==>  X  A  "z)  /\ 

(x  /\  y  /\  z  ==>  "(x  A  “z))  A 
(-X  A  'y  A  'z  ==>  -(x  A  -z))" 

[  "out  =  X  /\  *z"  ] 


0  :  void 

#expaaid(COIJ_TAC) ; ; 

OK.  . 

2  subgoals 

"(x  A  y  A  z  ==>  "(x  /\  "z))  A  ("x  /\  "y  A  "z  ==>  '(x 
[  "out  =  X  /\  "z"  ] 

"x  /\  y  A  "z  ==>  X  A  'z" 

[  "out  =  X  /\  "z"  ] 

0  ;  void 

#expaiid(STRIP_TAC  THEM  ASM_REWRITE_TAC [] ) ; ; 

OK.  . 

goal  proved 

I-  X  /\  y  A  "z  ==>  X  /\  *z 
Previous  subproof: 

"(x  A  y  A  z  ==>  *(x  A  'z))  A  (*x  A  "y  A  'z  ==>  *(x 
[  "out  =  X  /\  *z"  ] 


()  :  void 

#expaiid(COIJ_TAC  THEM  STRIP.TAC  THEH  ASM_REWRITE_TAC  □  ) ; 
OK.  . 

goal  proved 

I-  (x  A  y  A  Z  ==>  *(x  A  -z))  A  (-X  A  'y  A  'z  ==>  - 
I-  (x  /\  y  A  *z  ==>  X  A  "z)  /\ 

(x  /\  y  /\  z  ==>  '(x  /\  "z))  /\ 

("x  /\  'y  /\  'z  ==>  '(x  /\  "z)) 

I-  (out  =  X  A  *z)  ==> 

(x  /\  y  /\  'z  ==>  out)  /\ 

(x  /\  y  A  z  ==>  "out)  /\ 

('X  A  'y  A  'z  ==>  'out) 

I-  !x  y  z  out.  impl2_spec  x  y  z  out  ==>  behave.spec  x  y 

Previous  subproof: 
goal  proved 
()  :  void 


A  -z))" 


A  -z))" 


(x  A  'z)) 


z  out 
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The  previous  two  HOL  proofs  demonstrate  several  points.  The  first  and  obvious  point  is  that 

'i  X  y  z  out.  impllspec  x  y  z  out  =>  behave.spec  x  y  z  out  (16) 

and 

'i  X  y  z  out.  impl2^pec  x  y  z  out  ^  behave^spec  x  y  z  out  (17) 

demonstrate  how  a  structural  specification  can  be  shown  through  a  formal  proof  to  satisfy  a  behav¬ 
ioral  specification.  Secondly,  several  proof  steps  may  be  combined  into  one  step.  The  final  point  is 
that  the  choice  of  tactic  is  determined  by  the  appearance  of  the  theorem. 

The  two  previous  proofs  were  performed  using  tactics  available  in  an  older  version  of  HOL. 
The  most  recent  release  of  HOL  was  obtained  within  a  week  prior  to  this  report.  A  new  library 
has  been  added  to  HOL  that  includes  a  number  of  new  tactics  for  propositional  calculus.  One  new 
tactic,  called  TAUT.TAC,  determines  if  a  theorem  is  an  instance  of  a  tautology  of  the  propositional 
calculus.  The  last  proof  of 


V  X  y  «  out.  impl2.spec  y  z  out  behave.spec  x  y  z  out 


(18) 


will  demonstrate  its  use. 

#8et_goal([] ,"!x  y  z  out. 

#  iaipl3_spec  y  z  out  ==>  behave.spec  x  y  z  out");; 

"!x  y  z  out.  impl3_spec  y  z  out  ==>  behave.spec  x  y  z  out" 

0  :  void 

#load_library  'taut';; 

Loading  library  'taut'  ... 

;;  Fast  loading  lil«  "/usr2/hol/Library/taut/taut_iiil.o" 


Library  'taut'  loaded. 

()  ;  void 

#expand(REPEAT  GEI_TAC  THEI  REWRITE_TACCiBpl3_8pec;behave_8pec]  ) ; ; 
OK.  . 
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"(out  =  y  /\  *z)  ==> 

(x  A  y  /\  "z  ==>  out)  /\ 

(x  A  y  /\  z  ==>  'out)  /\ 

('x  A  'y  /\  "z  ==>  "out)" 

()  :  void 

#expaud(TAUT_TAC) ; ; 

OK.  . 

goeil  proved 

1-  (out  =  y  /\  'z)  ==> 

(x  A  y  /\  "z  ==>  out)  /\ 

(x  A  y  A  z  ==>  'out)  /\ 

(*x  /\  "y  /\  *z  ==>  'out) 

I-  !x  y  z  out.  implS.spec  y  z  out  ==>  behave.spec  x  y  z  out 

Previous  subproof : 
goal  proved 
()  :  void 

« 


Demonstrated  within  this  section  is  one  formal  hardware-verification  methodology.  In  this 
case,  the  behavioral  and  structural  specifications  were  written  in  VHDL.  In  order  to  prove  that 
the  structural  specifications  implied  the  behavioral  specification,  it  was  necessary  to  translate  the 
VHDL  specifications  into  HOL  definitions.  The  HOL  definitions  were  then  used  to  form  theorems. 
The  theorems  were  then  proven  through  the  use  of  tactics  in  HOL.  The  proof,  in  each  case,  formally 
verified  that  the  structural  specification  implied  the  behavioral  specification.  This  process  illustrates 
how  VHDL  descriptions  may  be  compared  through  HOL. 


Ill 


Appendix  D.  Translating  Data  Flow  to  Structure 


Introduction 

The  purpose  here  is  to  present  plausible  mappings  between  one  “style”  of  VHDL^  to  another 
“style”  of  VHDL.  By  the  term  “style”,  we  mean  a  VHDL  description  containing  VHDL  constructs 
acceptable  to  a  computer-aided  design  (CAD)  system.  Currently,  vendor  design  tools  are  not 
sufficiently  sophisticated  to  accept  the  entire  VHDL  language.  As  such,  a  vendor  will  specify  a 
“style”  of  VHDL  acceptable  for  their  tool  which  is  usually  a  subset  of  the  VHDL  language.  This  is 
the  same  for  vhdlSges  (Dukes  91b). 

A  Prolog-parser  called  vhdLparser^  is  used  to  generate  a  Prolog  intermediate  form  of  the 
VHDL  model  to  be  translated.  The  translated  intermediate  form  is  translated  back  to  VHDL  using 
the  pretty-printer,  write_vhdl_desigii_units/4,  included  in  vhdLparser.  The  Quintus^  Prolog 
environment  is  used. 

The  OveraU  Translation  Process  There  are  three  translations  being  performed.  The 
first  translation  takes  a  VHDL  description  and  generates  a  Prolog-intermediate  form  as  defined  by 
vhdLparser.  The  second  translation  involves  applying  a  mapping  from  one  VHDL  construct  (as  it  is 
represented  in  the  Prolog-intermediate  form)  to  another  VHDL  construct  (the  goal  of  this  project). 
In  essence,  a  Prolog-intermediate  form  is  generated  from  another  Prolog-intermediate  form.  The 
final  translation  generates  a  VHDL  description  from  the  Prolog-intermediate  form. 

Assumptions  There  are  a  few  assumptions  concerning  what  is  acceptable.  The  first  as¬ 
sumption  is  that  the  VHDL  provided  to  vhdLparser  is  correct  VHDL.  One  method  of  determining 
the  correctness  of  the  VHDL  model  is  to  have  it  analyzed  through  Zycad^  VHDL.  Another  assump- 

'VHDL  as  defined  by  the  IEEE  std  1076-1987  VHDL  Language  Reference  Manned,  hereikfter  called  LRM. 

^Copyright  1990  by  the  Microelectronics  Center  of  North  Carolina  (Reint  90) 

^Quintus  etnd  Quintus  Prolog  are  trademarks  of  Quintus  Computer  Systems,  Inc. 

‘Zycad  VHDL  is  a  trademark  of  Synopsis,  Inc. 


112 


tion  is  that  vhdLparser  works  correctly.  Oddly,  some  errors  have  been  uncovered  with  vhdLparser, 
however,  we  need  this  for  a  small  “sanity  check.” 

The  purpose  of  this  section  is  to  present  an  overview  of  the  Prolog-intermediate  form  used 
to  represent  VHDL  models.  The  Prolog-intermediate  form  is  generated  from  a  VHDL  model  using 
vhdLparser.  'I  he  documentation  accompanying  the  vhdLparser  did  not  include  a  description  of 
the  Prolog-intermediate  form.  Therefore,  this  chapter  should  be  helpful  to  others  trying  to  use 
vhdLparser. 

The  basic  Prolog  representation  for  a  VHDL  model  is  de8ign_unit/2.  The  first  term  of 
design_umt/2  is  a  description  of  the  library  or  package  dependencies  for  the  particular  design 
unit  under  consideration.  No  detailed  understanding  of  the  first  term  is  required,  but  is  mentioned 
only  for  completeness. 

The  second  term  of  design-unit /2  is  of  great  importance,  since  it  holds  the  Prolog-inter- 
mediate  form  for  a  package,  package  body,  entity,  configuration,  or  architecture.  The 
configuration  is  not  directly  related  to  this  project. 

The  entity  The  format  for  an  entity  is  the  following, 
des ign.unit (Use, ent ity ( Ent itylaoe , Generics , PortNap , Declarat ions , Ent ityBody ) } . 

The  terms  and  types  of  entity/5  are  shown  in  Table  4.  For  the  following  VHDL  model  of  an  entity. 


entity  fnll_part  is 

generic (constant  tPLH  ;  tine); 
port(a,b  :  in  bit; 

c  ;  out  bit) ; 
attribute  loc: integer; 
begin 

process  (b) 
begin 

assert  (a  =  ’O’); 
end  process; 
end  lull-part; 
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the  following  Prolog-intermediate  form  results 


design.unitC 

CD. 

•ntity( 
f  ull_p2urt , 

C 

intsrlacs.elemant (constant, Ctplh] .null, 
vhdl_8ubtyp«(null , tiae .null) .null .null) 

]. 

C 

interfaca.al ament (null. [a.b] ,in,vbdl_subtype(null,bit,null) .null, null) , 
intaTface_eleaent(null. [c] . out, vhdl.subtype (null, bit, null) .null, null) 

]. 

Cattribute_declaration(loc , integer)] , 

[ 

vhdl_proce88( 

null, 

Cb], 

[]. 

[a88ert(azpr(a,=,char(48)) .null, null)]  ) 

]  )). 


Table  4,  Terms  and  Types  of  entity/5 


Terms 

Types 

EntityName 

Generics 

PortMap 

Declarations 

EntityBody 

atom 

list_ofJnterface_elements 

list^fJnterface_elements 

list.of.declarativejobjects 

list.of.concurrentjstatements 

The  architecture  The  format  for  an  architecture  is  the  following. 


archfArchitecturelaae.Entitylane.Delcarations.ArchitectureBody) . 


The  terms  and  types  of  architecture/4  are  shown  in  Table  5.  From  the  following  VHDL  model 
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architflctur*  full_part  of  full.part  is 
signal  d  :  bit; 
begin 

c  <=  a  2uid  b; 
end  full_part; 


the  following  Prolog-intermediate  form  is  generated. 


design_nnit( 

□  . 

arch( 

f ull_part , 
f ull_part , 

[ 

ob j  ect.declarat ion ( 

signal, [d] ,vhdl_subtype (null, bit .null) .null, null) 

]. 

C 

csas( 

null, 

csa( 

c, 

null, 

null, 

C 

vave( 

[ 

event (expr (a, Sind, b)  .null) 

3, 

null  ) 

3  )) 

3  )). 


Table  5.  Terms  and  Types  of  architecture/4 


Terms 

Types 

ArchitectureName 

EntityName 

Declarations 

ArchitectureBody 

atom 

atom 

listjof.declarativejobjects 

listjof_concurrentj5tatements 
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The  package  The  format  for  a  package  is  the  following. 


packageCPackagelaae.Delcarations) . 

The  terms  and  types  of  package/2  are  shown  in  Table  6.  From  the  following  VHDL  model 

package  Functions  is 

type  opcode  is  (octO,  octl,  oct2,  oct3,  oct4.  oct6,  oct6,  oct7); 
function  smenonic  (bit .pattern  :  in  opcode)  return  integer; 
procedure  anenonic  (bit.pattem  :  in  opcode ; emsser  :  out  integer); 
end  Functions; 

the  following  Prolog-intermediate  form  is  generated. 
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design.uaitC 

□  . 

package ( 
lonctions, 

[ 

vhdl.typa ( opcode , [octO , oct 1 , oct2 , oct3 , oct4 , octS , oct6 , oct7] ) , 
sub.prograaC 
sub_spec( 
mnemonic , 

C 

inter! ace.element ( 
null, 

[bit_pattem] , 
in, 

vhdl.eubtype (null , opcode , null) , null , null) 

]. 

integer  ) , 
null  ), 
sub_program( 

8ub_8pec( 
mnemonic , 

L 

interface.elementC 

null, 

[bit.pattern] , in, 

Thdl_8ubtype(null, opcode, null) , 

null, 

null  ) , 

interface.elementC 
null , 

[^al8¥er]  ,  out , 

vhdl_8ubtype(null , integer , null) , 

null, 

null  ) 

]. 

null  ) , 
null  ) 

3  )). 


Table  6.  Terms  and  Types  of  package/2 


Terms 

Types 

PackageName 

Declarations 

atom 

listjof-declarativejobjects 
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The  package  body  The  format  for  a  package  body  is  the  following. 


package.body ( Packagelame , Oelcarat ions ) . 


The  terms  and  types  of  package  J>ody/ 2  are  shown  in  Table  7.  From  the  following  VHDL  model 


package  body  functions  is 

function  mnemonic  (bit.pattern  :  in  opcode)  return  integer  is 
variable  a,b,c  :  integer;  —  just  for  noise 
begin 

a  :=  b  +  c; 

case  bit.pattem  is 

when  octO  =>  retum(a) ; 
shen  octl  =>  retum(a+b) ; 
when  oct2  =>  retum(a+c); 
when  oct3  =>  retum(a-fa) ; 
when  oct4  =>  retum(b+c)  ; 
when  octS  =>  retum(b+b) ; 
when  octe  =>  retum(c+c) ; 
when  oct7  =>  return(b) ; 
end  case; 
end  mnemonic; 

procedure  mnemonic  (bit .pattern  :  in  opcode ; answer  :  out  integer)  is 

variable  a,b,c  :  integer;  —  just  for  noise 
begin 

a  :=  b  +  c; 

case  bit.pattern  is 

when  octO  =>  answer  :=  a; 
when  octl  =>  answer  :=  a+b; 
when  oct2  =>  answer  ;=  a-t-c; 
when  oct3  =>  answer  :=  a-t-a; 
when  oct4  =>  answer  :=  b+c; 
when  oct5  =>  answer  :=  b+b; 
when  oct6  =>  answer  :=  c-<-c; 
when  oct7  =>  answer  :=  b; 
end  case; 
end  mnemonic; 

end  functions; 


the  following  Prolog-intermediate  form  is  generated. 
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design.unitC 

n. 

package_body( 

functions, 

[ 

sub_progr^uB( 
sub_8pec( 
mnemonic . 

[ 

interlace.element ( 
null, 

Cbit_pattern] , in, 
vhdl_subtype(null, opcode, null) , 
null, 
null  ) 

]. 

integer  ) , 
program.body ( 

C 

object_declaration( 

variable, 

[a,b,c] , 

vhdl.subtype (null , integer , null) , 

null, 

null  ) 

]. 

C 

as8ign(a,expr(b,+,c)) , 
ca8e( 

bit.pattem, 

C 

vhdl_case(  [octO]  ,  Cretum(a)]  ) , 
vhdl_ca8e(  [octl]  ,  [retum(expr(a,  +  ,b))]  ) , 
vhdl_ca8e([oct2] ,  Cretum(expr(a,  +  ,c))]) , 
vhdl_ca8e(  [oct3]  ,  Cretum(expr(a,  +  ,a))]  )  , 
vhdl_ca8e(  [oct4]  ,  Cretum(expr(b,  +  ,c))] ) , 
vhdl_ca8e(Coct6]  ,  Cretum(expr(b,  +  ,b))] ) , 
vhdl_ca8e(  [oct6]  ,  [retum(expr(c,  +  ,c))]  )  , 
vhdl_ca8e( [oct7] , [return (b)] ) 

]  ) 

3  )). 

8ub_program( 

8ub_8pec( 
mnemonic , 

[ 

interface_element(null, [bit .pattern] ,in, 
vhdl_8ubtype (null, opcode, null) , null, null) , 
interface_element(null, [ansver] ,out, 

vhdl_8Ubtype(null , integer , null) , null , null) 

]. 

null  ) , 
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prograiB_body( 

[ 

object_decleu:ation(variable, Ca.b.c] , 

vhdl_s'abtype(null , integer , null) .null .null) 

3. 

[ 

assign(a.expr(b,  +  ,c)) , 
case( 

bit_pattem, 

C 

vhdl_ca8e( [octO] , Ca88ign(ansuer,a)] ) , 
vhdl_ca8e(  [octl]  ,  Ca8sign(ansuer,expr(a,-<-.b))]  )  , 
vhdl_ca8e(  Coct2]  ,  [a88ign(an8ffer,expr(a,-*-,c))] ) , 
vhdl_ca8e(  [oct3)  ,  [a88ign(an8uer,expr(a,-t',a))l)  , 
vlidl_ca8e( Coct4]  .  [a88ign(an8Her,expr(b,-)-,c))3)  , 
vhdl_caae(  [oct5]  .  Ca88ign(an8ser,expr(b,-i-,b))]  )  , 
vhdl_ca8e( [octe]  ,  [a88ign(an8uer,expr(c,->-.c))])  , 
vhdl_ca8e( [oct73 , [assign(ansver ,b)] ) 

3  ) 

3  )) 

3  )). 


Table  7.  Terms  and  Types  of  package  J>ody/2 


Terms 

Types 

PackageName 

Declarations 

atom 

listjof-declarativejobjects 

Translating  Data  Flow  to  Structure 

Analysis  of  the  VHDL  Model  Data-flow  VHDL  models  express  the  composition  of  cir¬ 
cuits  at  a  gate  level.  Each  data-flow  statement  is  a  digital-logic  expression,  representing  a  result  in 
terms  of  the  logical  composition  of  its  sig.  .  's.  An  example  of  a  data-flow  statement  is 


architecture  data.flov  of  example  is 
signal  a,b,c,d  :  bit; 
begin 

a  <=  b  and  c  or  d; 
end  data.flov; 
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A  data-flow  statement  also  contains  implicit  properties.  One  such  property  is  a  signal  connecting 
the  result  of  b  and  c  to  the  following  or  operator.  An  equivalent  structural  VHDL  construction 
would  look  like 


architecture  structural  of  example  is 
signal  a,b,c,d  :  bit; 
signal  internal.signal  :  bit; 
component  and.gate 

port(a,b  ;  in  bit; 

c  ;  out  bit) 
end  component; 
component  or.gate 

port (a, b  ;  in  bit; 

c  :  out  bit) 
end  component; 
begin 

and.gate  :  and_gate 

port  map(b,c,internal_signal); 
or_gate  :  or_gate 

port  map(internal_signal,d,a) ; 
end  structural; 


Another  implicit  property  of  the  data-flow  statement  is  that  all  logical  connectives  are  binary 
operators  except  for  the  NOT  operator.  NOT  is  an  unary  operator.  In  consideration  of  the  lan¬ 
guage  operators,  AND,  OR,  NAND,  NOR,  XOR,  and  NOT,  we  need  only  consider  implicit 
signal  declarations  and  six  different  components  declarations.  There  are  then  two  requirements  for 
translating  data-flow  VHDL  models  to  structural  models.  Implicit  internal  signals  must  be  gener¬ 
ated,  declared,  and  placed.  Secondly,  the  necessary  components  must  be  declared  and  instantiated 
with  the  correct  interconnecting  signals. 

In  order  to  analyze  the  Prolog-intermediate  form  generated  for  a  full  VHDL  description  of  a 
data  flow  model,  we  will  choose  a  description  of  a  full  adder,  shown  below. 
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entity  full_adder  is 

port  (A.B.Cin  :  in  bit; 

Sum, Carry:  out  bit); 
end  lull.adder; 

architecture  data.lloa  of  lull.adder  is 
signal  interml  :  bit; 
begin 

interml  <=  a  xor  b; 

sum  <=  interml  xor  cin; 

carry  <=  (a  and  b)  or  (a  and  cin)  or  (b  and  cin) ; 
end  data_flow; 


The  Prolog-intermediate  form  generated  for  the  entity  is  the  following. 


design_unit( 

n. 

entityC 

full_adder , 
null, 

C 

interface_element(null, [a,b,cin] ,in, 
vhdl_subtype(null , bit , null) , null, null) , 
interface_element(null, [sum, carry] ,out, 
vhdl_8ubtype(null , bit , null) , null, null) 

]. 

n. 

[]  )). 


The  Prolog-intermediate  form  generated  for  the  architecture  is  the  following. 


design_unit( 

□  . 

arch( 

data_llow, 
full_adder , 

[ 

object_declaration(signal, [interml] , 
vhdl_  subt  ype(null, bit, null), null , null ) 

]. 

[ 
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csas( 

null, 

csa( 

interml , 

null, 

null, 

C 

uave( 

C 

event ( 

expr(a,xor,b) , 
null) 

3. 

null  ) 

3  )). 

csas( 
null , 

C8a( 

sum, 

null, 

null, 

C 

uave( 

C 

event ( 

expr (interml , xor, cin) , 
null  ) 

3. 

null  ) 

3  )). 

csas( 

null, 

csa( 

carry, 

null, 

null, 

[ 

wave( 

[ 

event ( 
expr( 
expr( 

expr (a, and, b) , 
or, 

expr (a, and, cin)  ), 
or, 

expr (b, and, cin)  ), 
null  ) 

3. 

null  ) 

3  )) 
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]  )). 


From  the  Prolog-intermediate  form,  we  are  interested  in  two  items.  The  first  is  the  explicit 
signal  declarations  in  the  entity  and  architecture.  The  second  item  is  the  expression  trees  formed  by 
the  concurrent  signal  assignment  statements.  Figure  27  shows  the  three  expression  trees  formed  by 
the  three  concurrent  signal  assignment  statements  from  architecture  data_flow  of  fuU^dder. 


Figure  27.  Expression  Trees  from  Concurrent  Signal  Assignment  Statements. 

Generating  Structural  VHDL  The  Prolog  written  to  translate  from  data-flow  VHDL  to 
structural  VHDL  generated  the  following  result. 


—  VHDL  DESIGI  UIIT  #1 
entity  full.adder  is 
port 

(a,  b,  cin: in  bit ; 
sum,  carry: out  bit); 

end  full_adder; 

— •  VHDL  DESIGI  UIIT  #2 

architecture  sic_data_flov  of  full_adder  is 
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component  not.gate  generic 

(constant  tplh:time  0  ns; 
constant  tphl:time  :=  0  ns); 
port 

(a: In  bit; 
b:out  bit); 
end  component  ; 
lor  all  :  not .gate 
use  entity  vork. inv(inv) 

f 

component  xor.gate  generic 

(constant  tplh:time  :=  0  ns; 
constant  tphl:time  :=  0  ns); 
port 

(a,  b:in  bit; 
c:out  bit) ; 
end  component  ; 
lor  all  :  xor.gate 
use  entity  Hork.xor_gate(xor_gate) 

> 

component  or.gate  generic 

(constant  tplh:time  :=  0  ns; 
constant  tphl:time  :=  0  ns); 
port 

(a,  b: in  bit; 
c:out  bit); 
end  component  ; 
lor  all  :  or_gate 
use  entity  «ork.or_gate(or_gate) 

$ 

component  and.gate  generic 

(constant  tplh:time  :=  0  ns; 
constant  tphl:time  :=  0  ns); 
port 

(a,  b:in  bit; 
c:out  bit) ; 
end  component  ; 
lor  all  :  and.gate 
use  entity  sork.and_gate(and_gate) 

I 

signal  map_d2s0 : bit ; 
signal  map_d2sl :bit; 
signal  map_d2s2 : bit ; 
signal  map_d2s3 ; bit ; 
signal  map_d2s4:bit; 
signal  interml:bit; 
begin 

xor.gateO  :  xor.gate  generic  map 
(0  ns,  0  ns) 
port  map 

(a,  map_d2s0,  interml) 
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not.gateO  :  not.gate  generic  map 
(0  ns,  0  ns) 
port  map 

(b,  map_d2s0) 

• 

xor.gatel  :  xor.gate  generic  map 
(0  ns,  0  ns) 
port  map 

(interml,  cin,  sum) 

> 

or.gateO  :  or_gate  generic  map 
(0  ns,  0  ns) 
port  map 

(map_d2sl,  map_d2s2,  carry) 

$ 

or.gatel  :  or.gate  generic  map 
(0  ns,  0  ns) 
port  map 

(map_d283,  map_d2s4,  map_d2sl) 

$ 

and.gateO  :  and.gate  generic  map 
(0  ns,  0  ns) 
port  map 

(a,  b,  map_d2s3) 

I 

and.gatel  :  and.gate  generic  map 
(0  ns,  0  ns) 
port  map 

(a,  cin,  map_d2s4) 

and_gate2  :  and.gate  generic  map 
(0  ns,  0  ns) 
port  map 

(b,  cin,  map_d2s2) 


end  sic.data.flos; 

From  the  structural  VHDL  code,  the  following  may  be  noticed.  The  correct  component  declarations 
were  made  only  for  those  components  to  be  instantiated.  Declaring  components  that  are  not 
instantiated  later  can  cau.se  errors  for  some  VHDL  design  systems.  The  correct  signals  were  declared 
for  the  implicit  signals  in  the  data-flow  model.  Lastly,  all  of  the  components  were  instantiated  for 
those  operators  in  the  data-flow  model. 


126 


Limitations  and  Features  Currently,  the  translator  does  not  handle  signals  declared 
through  the  alias  keyword.  Furthermore,  the  translator  has  not  been  adapted  to  consider  bit.vector 
signals.  Other  nondata-flow  constructs  in  the  architectural  body  of  the  VHDL  model  under  con¬ 
sideration  are  not  touched.  Therefore,  sequential  data-flow  statements  within  a  process  are  not 
translated. 

Since  a  VHDL  model  may  have  component  instantiations  mixed  with  data-flow  statements, 
passing  nondata-flow  language  constructs  through  untouched  would  yield  the  benefit  of  deriving  a 
fully  structural  model  from  a  mixed  data-flow /structural  VHDL  model.  Handling  bit_vectors  was 
also  not  considered  in  this  step  since  it  could  be  handled  by  another  translation  step.  Therefore, 
the  translation  from  data-flow  to  structure  could  be  kept  simple. 

Running  d2s 

d2s  is  tested  through  the  use  of  the  make  utility  in  much  the  same  manner  as  case2if.  This 
is  to  help  reduce  the  number  of  keystrokes  necessary  to  accomplish  the  task  of  building  d2s  and 
testing  it.  Dependencies  are  set  up  for  all  test  cases  so  that  if  d2s  has  not  been  built,  it  will  be 
automatically  before  testing.  The  expected  results  are  kent  in  a  directory  called  data.  Thus,  the 
Unix  dtff  utility  may  be  used  to  compare  the  actual  output  of  d2s  with  the  expected  in  each  test 


The  two  test  cases  were  derived  in  this  fashion.  d23  was  written  first.  The  VHDL  models 
generated  by  d2s  were  then  analyzed  and  simulated  for  comparison  against  the  original  model.  The 
two  results  are  placed  in  the  directory  called  data. 

The  procedure  for  logging  into  VERIFY.EL.WPAFB.AF.MIL  and  running  the  test  cases  is 
the  same  as  for  case2if.  The  two  test  cases  are  explained  below. 

cldata  This  test  cjise  is  a  VHDL  model  of  a  full  adder  described  using  concurrent  signal  assignment 
statements. 
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form?  This  test  case  is  a  model  of  a  seven-input  parity  generator.  The  components  were  arranged 
in  such  a  fashion  to  provide  as  large  a  concurrent  signal  assignment  statement  as  possible. 
Included  in  this  VHDL  model  is  a  process  statement. 
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Prolog  Code  for  d28 


y//.y.mm%xx%my.xy.xxmmm%mmmxxmmmm.*my.y.y.y.y.y,m 

y.y.y.%y.%y.y.m%my.%y.y.%%y.mmy.xmmxm%xxmmxmmmmy.m 


d2s/l  is  a  Prolog  routine  to  convert  a  VHDL  aodel 

vitb  data  flow  constructs  to  an  equivalent  VHDL  model 
with  component  instantiations.  d2s/l  calls  upon  vhdl_read/l 
of  vhdl.parser  to  parse  the  original  VHDL  model. 

The  expression  trees  formed  by  the  VHDL  concurrent 
signal  assignment  statements  are  used  to  generate  the 
necessary  implicit  signal  declarations  as  sell  as 
components.  Finally,  the  neu  VHDL  model  is  generated  through 
urite_vhdl_design_units/4  using  a  pretty-printer 
supplied  in  vhdl.parser. 

Limitation:  In  order  to  ensure  all  signal  decl2a'ations  sure 
available  for  use,  an  entity  «ith  its  respective 
architecture  must  exist  in  the  one  VHDL  file  supplied. 

d2s/l  must  be  loaded  into  vhdl.parser!  The  command  is 

y.  vhdl.parser 

Quintus  Prolog  Release  2.4  (VAX,  Ultrix  2. 0-2. 2} 

Copyright  (C)  1988,  Quintus  Computer  Systems,  Inc.  All  rights  reserved. 

1310  Villa  Street,  Mountain  Vies,  CsQifomia  (418)  966-7700 

I  ?-  compile(d2s) . 

Afteruards,  save  the  executable  image  in  the  following  manner... 

I  ?-  save(d2s) . 


Execute  by  the  following: 
I  ?-  d2a(foo). 


Several  tables  are  built  in  memory. 
signal.name(lame) . 

expression. tree(Re8ultIame, Tree) . 

comp_table(lame,lum) . 


So  we  don’t  have  duplicate 
signal  names. 

Where  the  data.flow  statements 
are  stored. 

Components  to  be  declared. 

And  number  instantiated. 
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%  new.signal.naMe.nuBduB) . 
%  ne«_signal_naBe(Iaae} . 


■tuber  of  hov  aiany  signal 
names  have  been  generated, 
lame  of  nem  signal 


d2s(File) 

vhdl_read(File,De8ignUnits) , 
map_d2s(DesignUnit8.I««D«8ignUnit8) . 
telK  *outf  ile.  vhd’)  , 

vrite.vhdl.design.unitsdesDesignUnits.O.L,  □  ) , 

Brite_li8t(L,0) , 

told. 


y.xxxxx%xxxxxxy.xxy.xy.xy.xxy.y.y.xy.%xx*my.y.xy.%y.%%%xx%%‘my.xy.y.y.y.xy.y.xy.xy.xxx 

X 

X  te8t/2  vas  supplied  for  testing  purposes. 


te8t( 

Cdesign.unit (Use , entityCEntitylame .Generic .Port .EntityDecl . EntityBody) ) . 
des ign.unit (Use . arch ( ir chlame . Ent itylame . ArchUecl . ArchBody ) )] . 
Cdesign.unit (Use . entity (Ent itylame .Generic .Port . Ent ityDecl .EntityBody) ) . 
de8ign_unit(Use,arch(ArchIame.EntityIame,levArchDecl.IevArchBody))]) 

I 

•  9 

map_d28_build_signal_name_table(Port} . 
map_d2a_build_signal_name_table(ArchDecl) . 
map_d28_build_ezpre8sion_tree_table(Arch6ody.levArcliBody} . 
map_d28_generate_nev_8ignals (Signals) . 
append(Signals , ArchDecl .leuArchDecl) . 
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y.y.y.%xy.xy.x%%%%y.xy.x%y.xxm%xxx%y.y.xy.y.y.mm%xx%x%x%xx%%xxmy.x%%%xn 

X 

X  Bap_d2s/2  Bain  driver  routine  lor  breaking  out  the  signal 

X  naBes  and  expression  tree  sith  the  VHDL  entity  and 

X  architecture  pair.  Signal  tables  are  built  froB 

X  the  entity  and  architecture.  CoBponents  are  contructed 

X  from  the  expression  trees  foned  by  the  concurrent 

X  signsG.  assignsent  stateBents.  II  the  one  entity 

X  and  architecture  rule  is  not  adhered  to.  a  naming 

X  is  issued. 


Bap_d2s ( 

[des ign_unit (UseE , ent ity (Ent itylaae . Generic .Port . Ent ityDecl . Ent ityBody ) ) . 
design.unit (UseA . arch( ArchlaBe .Entitylaae . ArchDecl . ArchBody ) )] . 

[des ign.unit (UseE. ent ity ( Ent itylase . Generic . Port . Ent ityDecl . Ent ityBody) ) . 
des ign.unit (UseA . arch ( Archlane . Ent itylaae . lenArchDecl . lenArchBody ) ) ] )  : - 

I 

»  $ 

Bap_d2s_build_signal_naBe_table(Port) . 

Bap_d2s_build_signal_naBe .table (ArchDecl) . 
Bap_d2s_build_expression_tree_table(ArchBody .lenArchBody) . 
Bap_d2s_generate_nev_signals (Signals) . 

Bap_d2s_generate_nev_coBps (CoBps) . 
append(Signals , ArchDecl . InterBArchDecl) . 
append(CoBp8 . IntemArchDecl .lenArchDecl) . 

Bap_d28(_._) 

nrite( ’Please  place  one  entity  and  its  associated') .nl. 
nrite( 'architecture  in  one  file  before  rerunning’) .nl. 
nrite( ’d28/l . ’) .nl. 
fail. 
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y.y.m%myj.y.yx//myx/.myy/my//OTmx/.y.y.y/^^^^^ 


y. 

%  Dap_d28_g«nerate_neH_comps/l  is  ussd  for  building  component 

declaration  in  the  declarative  region  of  the  2urchitecture. 


map_d28_generate_nesr_comps(  [ 
vhdl_comp( 
not_gate, 

C 

interface_element(constant, Ctplh] .null, 

vhdl.subtype (null, time, null) ,null,vhdl_assign(pl(0,ns))) , 
interface_element( constant. [tphl] .null, 

vhdl_8ubtype(null, time, null) ,null.vhdl_assign(pl(0.ns))) 

]. 

C 

interface_element(null, [a] .in, 

vhdl.subtype (null. bit, null) .null, null) , 
interface_element(null, [b] .out, 
vhdl_subtype(null .bit .null) .null, null) 

]  ). 

vhdl_spec(8pec(2Lll, not .gate) ,binding(entity_aspect( 
vhdl.name (prefix (uork) ,inv) , 
inv  ) , 
null, 

null  ))  I  Comps]) 
retract ( comp.table (no  t , _lum) ) , 

I 

*  » 

map_d2s_generate_new_comp8 (Comps) . 
map.d2s_generate_neu.comps( [ 
vhdl_comp( 

Gatelame, 

C 

interface_element(constant, Ctplh] .null, 

vhdl_subtype(null, time, null) ,null,vhdl_assign(pl(0.ns))) , 
interface_element(constant, [tphl] .null, 

vhdl. subtype (null .time .null) .null , vhdl_assign(pl(0 ,ns) ) ) 

]. 

c 

interface_element(null, [a.b] .in, 

vhdl.subtype (null, bit, null) .null, null) , 
interface_element(null, [c] .out, 

vhdl.subtype (null .bit .null) .null, null) 

]  ). 

vhdl. spec (spec (all, Gatelame) ,binding(entity.aspect( 
vhdl.name(prefix(vork) .Gatelame) , 

Gatelame  ) , 
null. 

null  ))  I  Comps]) 
retract(comp.table(lame,.lum)) , 

I 
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name ( '.gate’ .Suffix) , 
name (lame, Prefix) , 
append(Prefix, Suffix, GatelameList) . 
name(Gatelame,GatelameList) . 
map_d2s_generate_new_comp8 (Comps) . 
map_d2s_generate_nee_comps(  □  ) . 


y. 


y,  map_d2s_generate_neH_signals/l  is  used  for  generating  a  list 
%  of  signal  declarations  for  the  neely  formed  signals. 

%  The  signal  declarations  are  placed  in  the  delcarative 

y.  region  of  the  architecture. 


map_d2s_generat  e.nev.s ignals ( 

[object_declaration(8ignal, [lame] , 

vhdl_subtype(null, bit, null) ,null,null) lObjDeclList]) 
retract (neB_signal_name (lame) ) , 

I 

•  I 

map_d2a_generate_ne«_8ignals(0bjDeclList) . 
fflap_d2s_generate_nev_8ignal8 ( O ) . 

map_d28_build_signal_name_table( 

[int  erf ac  e. element ( _  s ig , S igLis  t , .mode , 

vhdl_subtype(null, bit, null) ,null,null) ISignallames] ) 
map.d2s.build.signal.name_list_table(SigList) , 

I 

•  I 

map_d2a.build.signal.name.table(Signallames) . 
map_d28.build.signal.name.table( 

Cob j  ect.declarat ion(.sig , SigList , 

Thdl_subtype(null, bit, null) .null, null) ISignallames] ) 
map_d28.build.8ignal.name.li8t.table(SigList) , 

I 

•  • 

map.d28.build_8ignal.name.table(Signallames) . 
map.d2s.build.8ignal.name_table ( C.DeclItem I Signallames] )  : - 

I 

•  » 

map.d2s.build.signal.name.table (Signallames) . 
map.d2s.build.8ignal.name.table(C] ) . 
map.d28.build.signal.name.table(null) . 
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yx//my.y.y.yOT/.mmyjxm^^ 


y. 

y,  m<ip_d2s_build_8ignal_na]ne_li8t_tabl«/l  builda  a  table  of 
X  declared  aignala.  The  table  is  used  to  keep  track 

y,  of  signals  that  are  edready  declared. 


nap_d28_build_signal_naBe_li8t_table( [Signal I SigList] )  : - 
assert (signal_name(Signal)) , 

I 

•  > 

map_d2s_build_8 ignal.name.list.table (SigList ) . 
map_d28_build_signal_naBe_list_table(  □  ) . 


yx/xmmxyxmyx/xm/mrmxy.y.yx/;m%y.%xxy.xxxyx4^^^^^^ 

yx/xmy.%yx/xmyxmy.xy.y.y.yx/x/xmy.y.y.y.yx.%y.yx.yxmy.y.^^^^^^ 


y. 

X  map_d2s_build_azpres8ion_tree_table/2  builds  a  list  of 
X  conponent  instantiations  to  be  placed  in  the  architecture 

X  body . 


map_d28_build_expression_tree_table( 

[caas (Trans, Csa) lArchBody] .lesArchBody) 

aap_d28_convert_csas_to_coBp(csa8(Trans,C8a) ,CompInst) , 

I 

•  > 

map_d28_build_expr es  s ion_tree .table ( ArchBody , Inter ArchBody) , 
append (Coaplnst , Inter ArchBody .levArchBody) . 
nap_d2s_bttild_expre88ion.tree_table( 

[Head | ArchBody] , [Head I levArchBody] )  ;  - 

I 

•  » 

■ap_d2s_build_ expression. tree.table(ArchBody,IeuArchBody) . 
map_d28.build.expression_tree.table( [] , [] ) . 


xxxxxxxxxxxxxxxxxxxxxxxy.y.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxy.xxmxx 

xxxxxxxxxxxxxxxxxxxxxxxmxxxxxxxxxxxxxxmxxxxxxxxxxxxxxxxxxxmx 

X 

X  ■ap.d28. convert. C8a8.to.coBp/2  is  used  for  bre2dcing  down 

X  an  expression  tree. 


aap_d28. convert. C8as.to.coap( 

csas (null, csa(SignallaBe, null, null, [uave([event(Expr,null)] ,null)])) , 
CoapInstList) 

nap.d2s.convert_expr.to_comp(Signalla»e , Expr , ConpInstList ) . 
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y. 


map_d2s_convert_expr_to_cofflp/2  is  vhere  the  component  is 
%  derived  from  cin  expression. 


map_d2s_convort_oxpr_to_comp( 

Signallame, 

expr(Opr .SignallameR) , 

[comp. instant (Compinstlame , CompHaiffle , 

[element (null , pi (0 , ns ) ) , element (null , pi ( 0 . ns ) ) ]  , 
[element (null, SignallameR) , 
element(null,Signallame)] )]  } 
at om (Signal lame R) , ! . 

map_d2s_get_comp_name_inst (Opr , CompInstHame , Complame) , 

I 

map_d2s_convert_expr_to_comp( 

Signallame, 
expr(0pr ,Expr) , 

[comp.insteuit (CompInstHame , Complame , 

[element (null , pi ( 0 , ns ) ) , element (null , pi ( 0 , ns ) ) ] , 
[element (null, Sign2dIameR) , 
element (null,SignalHaffle)] ) I CompListR]  ) 

I 

•  I 

map_d2s_get_comp_name_inst (Opr , CompInstHame , CompHame) , 
map_d2  s  _gen. s ignal .name ( S ignalHameR) , 
map_d2s_convert_expr_to_comp( 

SignalHameR, 

Expr, 

CompListR) , 

j  . 

map_d28_convert_expr_to_comp( 

SignalHame, 

expr ( S ignalHameL , Opr , S ignalHameR) , 

[comp. instant (CompInstHame ,CompH2UBe , 

[element(null,pl(0,ns)),el ement ( null ,pl(0,ns))], 
[element (null, SignalHameL) , element (null, SignalHameR) , 
element (null, SignalHame)] )]  ) 
atom(SignalHameL) , 
atom(SignalHameR) , ! , 

map.d2s.get.comp.name.inst (Opr, CompInstHame, CompHame) , 

I  _ 

map_d28_convert.expr.to.comp( 

SignalHame , 

expr (Expr , Opr, SignalHameR) , 

[comp. instant (CompInstHame , CompHame , 

[element (null, pi (0, ns)) , element (null, pi (0,ns))] , 
[element (null, SignalHameL) , element (null, SignalHameR) , 
element (null,SignalHame)] ) I CompListL]  ) 
atom(SignalHameR) , ! , 

map_d2s.get.comp_name.in8t (Opr , CompInstHame, CompHame) , 
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map_d2s_gen_signal_naiii«(SignalIaiii6L) , 
map_d28_convert_expr_to_comp( 

SignallaneL , 

Expr, 

CompListL) , 

!  _ 

inap_d28_convert_expr_to_comp( 

Signallame , 

expr (SignalMameL, Opr , Expr) , 

[comp_in8t2ait  (Complnstlaime .  Complame , 

Celement(null,pl(0.ii8)) ,element(null.pl(0,n8))] , 
[element (null .SignallameL) , element (null , SignallameR) , 
element(null,SignalMame)] ) ICompLietR]  ) 
atom(SignalRaffieL) . ! , 

map_d2s_get_comp_name_in8t(0pr,CoapInstIame,CompMame) . 
map_d2  8  _gen_  8 ignal.name ( S IgnalMameR) , 
map_d28_convert_expr_to_comp( 

SignalHameR. 

Expr, 

CompLi8tR) , 

!  _ 

map_d28_convert_expr_to_comp( 

SignalMame, 

expr ( ExprL , Opr , ExprR) , 

[comp.inetzuat (Complnetlame , Complame , 

[el ement (null ,pl ( 0 , ne ) ) , element (null , pi ( 0 , ne ) ) ]  , 
[element(null,SignalIaffleL) ,element(null,SignallameR) , 
element (null, Signallame)] ) I CompLiet]  ) 
fflap_d28_get .comp_naffle_in8t(0pr,CompIn8tRaffle, Complame) , 
map_d2s_gen_8ignal_name (SignallameL) , 
map_d28_gen_signal_name(SignalIameR) , 
map_d28_convert_expr_to_comp( 

SignallameL, 

ExprL, 

CompLietL) , 

map_d28_convert_expr_to_comp( 

SignallameR, 

ExprR , 

CompListR) , 

append(CompListL,CompListR,CompLi8t) , 
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% 


y,  map_d2s_gen_signal_name/l  builds  a  table  of  neuly  created 
y,  signals.  The  table  is  to  be  used  for  reconstructing 

%  the  decleurative  region  of  the  architecture  later. 


map_d2s_gen_signal_name(Signallaine) 

retract (nev_signal_name_num(liun) ) . 

! 

nameduffl.HuiiiList) , 
na]ne(map_d2s,IainAList) , 
appendClameList  .luBiList  .SiglameList) , 
nameCTmpSiglaffle.SiglameList) . 

map_d2s_retum_good_na]ne(Mu]n.TmpSigla]Be,IntNun,SignalHame) , 
leuIUB  is  IntluB  1. 
as  s  ert (nea_s ignal.name (Signallame) ) , 
assert (nev_signal_naiDe_num(lieHluB) ) , ! . 
map_d2s_gen_s ignal.name ( S ignalHame)  : - 
name(0,lu>BList) . 
nase  (inap_d2s  .laneList) , 
appendCHaaeList  .HuiiiList  .SiglameList) , 
nameCTmpSiglaffle.SigMaaieList) , 

map_d2s_return_good_name(0,TmpSigIame,IntIum,SignalName) , 
HesHum  is  Intium  1, 
assert (nev.s ignal.nane (Signsdlame) ) , 
assertCnew.signal.naffle.numdeuIuiB)) , ! . 


y.yx/x/x/x///.yx/x///.y//x/x/x//m////x/xmy//XOT 

yx///////x/////////x/x///;/////x/x/x/x///////////;///x/x/x/.yxm^ 

y. 


y,  inap_d2s_return_good_naae/4  is  used  to  ensure  that  a  newly 
y,  created  signal  name  doesn’t  already  exist. 


map_d2 s _r eturn.good.name (Rum , TmpS igRame,I««Riu>,S ignalHame )  : - 
signal_name(TmpSigHame) , 

I 

•  » 

Intium  is  Mum  1, 
name(map_d2a  ,I^uList) , 
name ( Intium. IntMumList) , 

append (lameList , IntlumList .IntSiglameList) , 
namedntSiglame ,  IntSiglameList) , 

I 

•  i 

map_d2s_return_good_name ( Intium , IntSiglame , lewlum , Signallame) . 
map_d2s_return_good.name (Rum , Siglame , lum.Siglame) . 
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y. 


y,  map_d2s_get_comp_name_in8t/3  is  used  to  generated  component 
'/  labels  in  the  archtectnxe  body. 


map_d2s_get_comp_name_inst(0pr,CompInstlame,CompIame) 
retract(comp_table(Opr,Ium)) , 

I 

•  > 

n2une(0pr  ,GateIame) , 

name( '.gate’ .Extension)  .  ‘/.I  knoe  this  looks  inefficient 

%but  I  sant  this  to  vork  on 
y.AIY  machine. 

append(GateIame .Extension, ComplameList) , 
name(Complame,CompNameList) . 
name(Hum,MumList) , 

append ( ComplameList , lumList . CompInstHameList ) , 
n2Lme(CompIn8tl2une,CompInstIameList) , 
levMum  is  lum  +  1 , 
assert(comp_table(Opr .leslum)) . ! . 
map_d28_get_comp_name_inst (Opr , CompInstHame . Complame)  : - 
name(Opr .GateVame) , 

name ( '.gate ’ .Extension) ,  knon  this  looks  inefficient 

‘/but  I  Bant  this  to  work  on 
y.AIY  machine. 

append(GateIame, Extension, ComplameList) , 
name(Complame, ComplameList) , 
name(0,lum) , 

append ( ComplameList , lum , CompInstlameList ) , 
nameCCompInstlame.CompInstlameList) , 
a8sert(comp_table(0pr , 1)) . 


y//.yy//.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y.y;/.y.y.y.yx/.yx/x/x/x/j///////////^^ 

y. 


y.  UTILITIES 


y. 


y,append(  []  ,L,L) . 

•/.append (  [H I  LI]  ,  L2 ,  [H I L3]  )  :  - 
•/  append(Ll  ,L2,L3)  . 


Corrections  to  vhdLparser 


The  first  correction  made  to  rAd/.parser  involved  the  proper  differentiation  between  package 
and  package  body.  Originally,  rAdLparscr  would  translate  the  following  VHDL 
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package  body  functions  is 


function  mnemonic  (bit.pattem  :  in  opcode)  return  integer  is 
veuriable  c  :  integer;  —  just  for  noise 
begin 
return(c) ; 
end  mnemonic; 

end  functions; 


to 


—  VHDL  DESIGM  UIIT  #1 
package  functions  is 

function  mnemonic (bit.pattem: in  opcode)  return  integer  is 
variable  c: integer; 

begin 

return  c; 
end  mnemonic; 
end  functions; 

which  produced  an  invalid  VHDL  package. 

The  corrections  made  to  vhdLparser  are  shown  below. 

In  the  file  vhdl.tex,  Rule  16  was  changed  from 


vhdl _package_body ( package (ID.DIs))  — > 

[  package,  body  ],  vhdl_identifier(ID) ,  [  is  ] . 

vhdl_opt_declarative_items (DIs) , 

C  end  ],  vhdl_opt_identif ier(ID) . 


to 


vhdl_package_body(package_body(ID,DIs))  — > 

[  package,  body  ],  vhdl_identifier(ID) ,  [  is  ] , 
vhdl_opt_declarative_item8{DIs) , 

[  end  ],  vhdl_opt_identif ier(ID) . 
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In  the  file  vhdl_write.tex,  Rule  16  was  changed  from 


writ  e_ vhdl_package_body (packageClD.DIs))  — > 

"package  body  ",  write_vhdl_identif ier(ID) ,  "  is  ", 
[indent] , 

Hrite_vhdl_opt_declarative_item8(DIs) , 

[undent] , 

"end  ",  write. vhdl_opt_identif ier(ID) . 


wr it  e_ vhdl_package_body (package.body ( ID , DIs ) )  — > 

"package  body  ",  write_vhdl_identilier(ID) ,  "  is  ", 
[indent] , 

write_vhdl_opt_declarative_item8(Dl8) , 

[undent] , 

"end  ",  write_vhdl_opt_identilier(ID) . 


Another  problem  encountered  with  vhdLparser  was  the  pretty-printing  of  physical  types.  For 
a  line  that  looks  like 


6  ns; 

the  pretty-printed  result  would  look  like 

6ns; 

leaving  a  syntactically-incorrect  VHDL  model.  In  order  to  correct  this  problem,  Rule  5  in 
vhdl_write.tex  was  changed  from 


write_vhdl_physical_literal(pl(AL,ID))  — > 
write_vhdl_abstract_literal(AL) , 
write_vhdl_identif ier(ID) . 


to 
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Brite_vhdl_phy8ical_literal(pl(AL,ID))  — > 
write_vhdl_ab8tract_literal(AL) ", 

Hrite_vhdl_identilier(ID) . 

Uncorrected  Problems  with  vkdLparstr 

Listed  in  this  appendix  are  errors  encountered  in  vhdLparser  that  have  not  been  corrected. 
Both  errors  involve  subtleties  with  special  characters  and  integers. 

The  first  error  involves  integer  representation  in  vhdLparser  when  a  bit_vector  is  intended. 
Leading  zeros  in  bit_vectors  are  dropped  due  to  the  conversion  to  integer  during  file  input  with 
vhdLgeLiokenJine/1 .  For  an  input  line  with  001  as  a  bit_vector,  the  resulting  representation  is 
1.  The  pretty-printed  VHDL  code  will  contain  a  syntax  error  due  to  this  problem. 

The  second  error  involves  the  use  of  the  quote  character,  •;  in  VHDL.  The  quote  character  is 
essentially  dropped.  Therefore,  an  assert  statement, 

assert  (expected  =  actual)  report  "conflict"  severity  error; 

is  reprinted  as 

assert  (expected  =  actual) 
report  conllictseverity  error; 

causing  a  syntax  error. 

Conclusion 

The  process  of  translating  data-flow  to  structure  was  successful  in  that  the  resulting  VHDL 
code  yielded  the  simulation  results  as  the  original  VHDL  code.  Separating  the  d2s  from  ges  allowed 
for  ease  of  testing,  isolation  from  changes,  and  ease  of  code  development.  Also  worth  noting  is  that 
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a  partial  datei-flow  VHDL  model  will  only  have  the  data-flow  portion  changed  by  d2s,  leaving  the 
rest  of  the  VHDL  model  alone. 

The  errors  found  in  vhdLparser  were  noted  and  fixed  as  indicated.  Not  all  errors  were  cor¬ 
rected.  The  errors  remaining  to  be  corrected  were  not  devastating  to  tool  development. 
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Appendix  E.  Formal  Methods 


Formal  methods  are  used  to  provide  a  systematic  basis  for  specifying,  developing,  and  verify¬ 
ing  relations  between  a  speciRcation  and  an  implementation  (Wing  90b:8).  Some  of  the  relations  or 
properties  examined  by  formal  methods  may  include,  but  are  not  limited  to,  equivalence,  implica¬ 
tion,  reliability,  safety,  liveness,  consistency,  or  completeness.  Some  formal  methods  familiar  to  the 
design  engineer  involved  in  VLSI  design  include  design-rule  checking,  synthesis,  silicon  compilation, 
and  petri  nets.  These  formal  methods  have  a  mathematical  basis;  however,  methods  that  involve 
ad  hoc  simulation  are  not  considered  formal. 

Logic  extraction  is  a  formal  method  that  is  used  to  verify  the  equivalence  between  a  component 
netlist  and  a  VHDL  structural  description.  The  VHDL  description  is  the  structural  specification 
and  the  component  netlist  represents  the  layout  specification*.  Furthermore,  logic  extraction  may 
also  be  used  to  examine  configuration  properties  (i.e.,  design  rule  checks),  reliability  properties, 
and  temporal  properties  of  a  digital  circuit. 

To  help  show  that  logic  extraction  is  a  formal  method,  we  will  use  the  notation 

Fha 

(Duffy  91:31-34,43-54)  where  F  is  a  set  of  assumptions  or  axioms  and  a  is  the  theorem  to  be  proved, 
r  sets  the  context  for  proving  the  theorem  q.  Another  way  of  expressing  F  h  a  is 

7i  A  . . .  A  7„  =>  a 


where  each  7,-  £  F  and  1  <  »  <  n. 


'  A  transistor  netlist  is  extracted  from  the  layout  specification  using  already-existing  CAD  tools. 


143 


Various  rules  of  inference  may  be  used  to  demonstrate  that  a  follows  from  F.  One  inference 
rule  is  the  rewrite  rule.  With  respect  to  F  h  q,  a  rewrite  rule  applies  a  replacement  in  o  specified 
by  some  7; .  The  replacement  is  not  necessarily  always  a  reducing  one.  For  7i  to  be  used  as  the 
basis  for  a  rewrite,  7,  must  be  in  the  form  t  =  t'.  A  replacement  occurs  through  a  rewrite  in  a 
when  some  expression  of  a  is  in  the  form  of  For  the  formula 

(C  =  A  AB)  h  C=^A'^B 

a  rewrite  would  result  in 

(C  =  AAB)  h  (A  A  B)  =>  (A  V  B). 

By  the  definition  of  F  h  a  the  formula  may  be  rewritten  as 

(C  =  AaB),A,B  I-  A  VB 

which  yields^ 

(C  =  AA  B),A,B  h  TVB 

and  finally 

(C=  AaB),A,B  h  T. 

In  a  logical  sense,  logic  extraction  may  be  viewed  as 


Extraction  Rules  t-  Layout  Specification  O  Structural  Specification 


*The  choice  of  matching  t  and  repl2K:ing  with  I'  versus  matching  t'  and  replacing  with  t  is  inconsequential  provided 
the  matching  is  done  to  prevent  an  infinite  matching/replace  cycle. 

^  T  is  used  to  denote  logical  true.  Each  "r,  is  assumed  true;  therefore,  everywhere  that  an  expression  in  or  matches 
a  7, ,  T  is  substituted  for  the  expression. 
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where  ExtractionRules  form  the  context  F  of  a,  the  Layout  Specification  is  represented  by  a 
component  netlist,  and  the  StructuralSpecification  is  the  top-level  component  represented  by  the 
specification.  Further  Layout  Specification  o  Structural  Specification  is  the  theorem  a. 

As  an  example,  consider  the  following. 

(ci(A:,y)Ac2(x.y)  =  c3(x,y)), 

(c3iX,Y)ACi{Y,Z)=.cs{X,Y,Z))  h  (cx(a,6)Ac2(a,6)Ac4(6,c))0C5(a,6,c)  (19) 

(ci(x,y)Ac2(A:,y)  =  c3(x,y)), 

{c3{X,Y)Ac,iY,Z)=cs{X,Y,Z))  h  (03(0,  fc)  A  04(6,  c))  o  05(0, 6,  c)  (20) 

(ci(A,y)Ac2(x,y)  =  c3(A,y)), 

(c3(A,y)Ac4(y,Z)  =  C5(X,y,Z))  t-  c^{a,b,c)^csia,b,c)  (21) 

In  Eq  19,  the  ExtractionRules  are  listed  as  the  assumptions  concerning  the  environment  of  the 
proof.  Also  included  is  a  list  of  the  components  from  the  LayoutSpecif  ication.  la  Eq  20,  a  rewrite 
of  the  LayoutSpecif  ication  has  been  applied  from  the  assumption  list.  The  derivation  in  Eq  20 
gives  a  new  representation  of  the  LayoutSpecif  ication,  but  not  in  a  form  readily  provable.  Finally, 
in  Eq  21,  another  rewrite  of  the  LayoutSpecif  ication  is  performed  from  the  list  of  assumptions. 
The  final  result  is  readily  proven  true. 

A  discussion  on  the  b^lsis  of  formal  methods  may  be  found  in  (Wing  89),  (Wing  90a),  and 
(Wing  90b).  Further  information  on  formal  methods  may  also  be  found  in  (MacLe  90:52-61), 
(Beth  62),  (Ramsa  91),  (Schar  88),  and  (Gordo  88). 
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